[Xen-devel] [qemu-upstream-4.7-testing test] 102701: regressions - FAIL

[osstest service owner]

flight 102701 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102701/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
100711
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 100711

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt   15 guest-start/debian.repeat fail blocked in 100711
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100711

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-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuue27a2f17bc2d9d7f8afce2c5918f4f23937b268e
baseline version:
 qemuue927b5f5a809f07b73b063831527c8a87f053933

Last test of basis   100711  2016-09-02 02:46:43 Z   88 days
Testing same since   102532  2016-11-22 20:11:32 Z6 days   11 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 

Re: [Xen-devel] [PATCH] libxl: invert xc and domain model resume calls in xc_domain_resume()

[Wei Liu]

On Mon, Nov 28, 2016 at 02:53:57PM +0100, Cédric Bosdonnat wrote:
> Resume is sometimes silently failing for HVM guests. Getting the
> xc_domain_resume() and libxl__domain_resume_device_model() in the
> reverse order than what is in the suspend code fixes the problem.
> 
> Signed-off-by: Cédric Bosdonnat 
 
I think it would be nice to explain why reversing the order fixes the
problem for you. My guess is because device model needs to be ready when
the guest runs, but I'm not fully convinced by this explanation --
guests should just be trapped in the hypervisor waiting for device model
to come up.

I also CC'ed other people who are more familiar with this area so that
they can provide insight.
 
Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

[Wei Liu]

On Mon, Nov 28, 2016 at 12:18:03PM -0500, Ronald Rojas wrote:
> Created basic Makfele for the Golang xenlight

Makefile.

> project so that the project is built and
> installed. A template template is alo added.

Duplicated "template".

> ---
>  tools/Makefile| 15 +++
>  tools/golang/xenlight/Makefile| 29 +
>  tools/golang/xenlight/xenlight.go |  7 +++
>  3 files changed, 51 insertions(+)
>  create mode 100644 tools/golang/xenlight/Makefile
>  create mode 100644 tools/golang/xenlight/xenlight.go
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 71515b4..b89f06b 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -11,6 +11,7 @@ SUBDIRS-y += misc
>  SUBDIRS-y += examples
>  SUBDIRS-y += hotplug
>  SUBDIRS-y += xentrace
> +SUBDIRS-y += golang/xenlight

This shouldn't be built unconditionally.

Please use configure to probe for go compiler first.

"GNU autotools" is the term to google for. But I guess it wouldn't be
too hard to follow existing examples.

Don't hesitate to ask questions.

>  SUBDIRS-$(CONFIG_XCUTILS) += xcutils
>  SUBDIRS-$(CONFIG_X86) += firmware
>  SUBDIRS-y += console
> @@ -311,6 +312,20 @@ subdir-install-debugger/gdbsx: .phony
>  subdir-all-debugger/gdbsx: .phony
>   $(MAKE) -C debugger/gdbsx all
>  
> +subdir-all-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight all
> +
> +subdir-clean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight clean
> +
> +subdir-install-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight install
> +
> +subdir-build-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight build
> +
> +subdir-distclean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight distclean
>  

I think I would prefer to organise this like python bindings. That is,
to have a dedicated Makefile under $LANG (python or golang) directory.

What do you think?

>  subdir-clean-debugger/kdd subdir-distclean-debugger/kdd: .phony
>   $(MAKE) -C debugger/kdd clean
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> new file mode 100644
> index 000..c723c1d
> --- /dev/null
> +++ b/tools/golang/xenlight/Makefile
> @@ -0,0 +1,29 @@
> +XEN_ROOT=$(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +BINARY = xenlightgo
> +GO = go

This should probably be:

  GO ?= go

> +
> +.PHONY: all
> +all: build
> +
> +.PHONY: build
> +build: xenlight
> +
> +.PHONY: install
> +install: build
> + [ -f $(BINARY) ] || $(INSTALL_PROG) xenlight.go $(DESTDIR)$(bindir)
> +
> +.PHONY: clean
> +clean:
> + $(RM) $(BINARY)

If there are other intermediate files generated, they should be deleted,
too.

> +
> +.PHONY: distclean
> +distclean: clean
> +
> +
> +xenlight: xenlight.go

xenlightgo: xenlight.go and delete BINARY

or

$(BINARY): xenlight.go

> + $(GO) build -o $(BINARY) xenlight.go

Use $@ instead of $(BINARY).  Use $< instead of xenlight.go.

But before we spend too much time on details, let's sort out some higher
level issues first. My golang knowledge is rather rusted, please bear
with me. :-)

I have a question: how does golang build a package that has multiple
files? Presumably it has some sort of file that acts like Makefile. If
so, you should probably introduce that now and use that to build this
package.

Otherwise in order to avoid repetition you probably need something like
the %.o: %.c rule in tools/Rules.mk.

If you need more information about GNU Make, please use `info make` on
your system or ask questions here.

> +
> +
> +-include $(DEPS)
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> new file mode 100644
> index 000..50e8d8d
> --- /dev/null
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -0,0 +1,7 @@
> +package main
> +
> +import "fmt"
> +
> +func main() {
> + fmt.Println("vim-go")

vim-go ?

> +}
> -- 
> 2.7.4
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko]

On 11/28/2016 07:12 PM, Julien Grall wrote:



On 28/11/16 17:11, Andrew Cooper wrote:

On 28/11/16 16:59, Julien Grall wrote:

Hi,

On 28/11/16 15:43, Oleksandr Andrushchenko wrote:

On 11/28/2016 05:00 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:56, Oleksandr Andrushchenko wrote:

On 11/28/2016 04:24 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:12, Oleksandr Andrushchenko wrote:


On 11/28/2016 03:27 PM, Jan Beulich wrote:

+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page
describing
+ *   page directory. Must be 0 if no more pages in the list.


If I am not mistaken 0 is a valid grant.


Then I will remove this sentence, anyways BE knows how many grefs
there
are for the buffer size given

BTW, xen-blkfrint.c:
#define GRANT_INVALID_REF0
this is from where I got "Must be 0 if no more pages in the list."


GRANT_INVALID_REF is internally to Linux and never exposed in the PV
driver. So for me it is implementation details because ref 0 could be
allocated (log dump by Xen):

(XEN)    active     shared 
(XEN) [ref] localdom mfn  pin  localdom gmfn flags
(XEN) grant-table for remote domain:2 (v1)
(XEN) [  0]0 0x99bf35 0x0001  0 0x039000 0x19
(XEN) [  1]0 0x99bf33 0x0001  0 0x039001 0x19


Grant reference 0 is reserved in the ABI for the paravirtual console.


Oh, so considering grant ref 0 as invalid in a PV protocol would be fine?

Just to summarize: strictly speaking, grant reference 0 is valid, but
never exposed to a PV driver, because of the fact that it is already in
use/reserved for the PV console. Taking into account this fact we can
assume that 0 is GRANT_INVALID_REF and can be used in PV
drivers just like xen-blkfront.c
does.

I will add a note on this in the protocol


Cheers,




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.6-testing test] 102700: regressions - FAIL

[osstest service owner]

flight 102700 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102700/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt 13 saverestore-support-check fail REGR. vs. 99723
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 99723
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
99723
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 99723

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99723
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 99723

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuba9175c5bde6796851d3b9d888ee488fd0257d05
baseline version:
 qemuuebfc90b51d09e0a3330a4702bb23223cf088eabd

Last test of basis99723  2016-07-27 18:10:12 Z  124 days
Testing same since   102530  2016-11-22 20:11:13 Z6 days   11 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 

[Xen-devel] [ovmf test] 102702: all pass - PUSHED

[osstest service owner]

flight 102702 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102702/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8ae17140476861efa642d28849f627fd9940f1af
baseline version:
 ovmf bb767506b265b1cdbf0dbec58c9a3f4c6be6ab2b

Last test of basis   102696  2016-11-28 13:13:57 Z0 days
Testing same since   102702  2016-11-29 01:52:01 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=8ae17140476861efa642d28849f627fd9940f1af
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ 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 ovmf 
8ae17140476861efa642d28849f627fd9940f1af
+ branch=ovmf
+ revision=8ae17140476861efa642d28849f627fd9940f1af
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ 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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x8ae17140476861efa642d28849f627fd9940f1af = x ']'
+ : 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/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v3 01/15] docs: L2 Cache Allocation Technology (CAT) feature document.

[Yi Sun]

On 16-11-25 18:19:17, Dario Faggioli wrote:
> On Fri, 2016-11-11 at 16:33 -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Oct 25, 2016 at 11:40:49AM +0800, Yi Sun wrote:
> > > --- /dev/null
> > > +++ b/docs/features/l2_cat.pandoc
> > > @@ -0,0 +1,314 @@
> > > +% Intel L2 Cache Allocation Technology (L2 CAT) Feature
> > > +% Revision 2.0
> > > +
> > > +\clearpage
> > > +
> > > +# Basics
> > > +
> > > + ---
> > > -
> > > + Status: **Tech Preview**
> > > +
> > > +Architecture(s): Intel x86
> > > +
> > > +   Component(s): Hypervisor, toolstack
> > > +
> > > +   Hardware: Atom codename Goldmont and beyond
> >
> Atom codename Goldmont and beyond CPUs
> 
> It may sound obvious, but I'd explicitly add that bit.
> 
Ok, thanks!

> > > + ---
> > > -
> > > +
> > > +# Overview
> > > +
> > > +L2 CAT allows an OS or Hypervisor/VMM to control allocation of a
> > 
> > Could you define CAT?
> > 
> > > 
> > > +CPU's shared L2 cache based on application priority or Class of
> > > Service
> > > +(COS). Each CLOS is configured using capacity bitmasks (CBM) which
> > > +represent cache capacity and indicate the degree of overlap and
> > > +isolation between classes. Once L2 CAT is configured, the
> > > processor
> > > +allows access to portions of L2 cache according to the established
> > > +class of service (COS).
> > > +
> > > +# Technical information
> > > +
> > > +L2 CAT is a member of Intel PSR features and part of CAT, it
> > > shares
> > 
> > Could you define 'PSR' here? Usually when you introduce an acronym
> > you do something like:
> > 
> > Intel Problem Solver Resolver (PSR)
> > 
> Wasn't it the 'Intel Probabilistic Silicon Reorganizer' ? :-D :-D
> 
It is 'Intel Platform Shared Resource' indeed. :-)

> > and that makes it easy for folks to map the acronym to the full
> > feature.
> > 
> Actually, given the density of acronyms, I'd say it would be good to
> add a "## Terminology" section at the top, and define all of them there
> upfront.
> 
Thanks! I will add this section.

> Also, I see that you're meaning this to be committed in tree and act as
> the L2 CAT feature document. I know that you've been asked to put it in
> tree (although, the request was for docs/misc/) and I think it's good
> to have a feature document for L2 CAT.
> 
> It contains a lot more technical details than the other (few) feature
> documents we have in tree right now. Personally, I'm fine with that,
> but I'd say that at least try to filling these sections would be
> important:
> 
> (from docs/features/template.pandoc)
> 
>   # Limitations
>   Information concerning incompatibilities with other features or
>   hardware combinations.
> 
>   # Testing
>   Information concerning how to properly test changes affecting this 
>   feature.
> 
>   # Areas for improvement
>   List of enhancements which could be undertaken, e.g. to improve the
>   feature itself, or improve interaction with other features.
> 
>   # Known issues
>   List of known issues or bugs.  For tech preview or experimental
>   features, this section must contain the list of items needing fixing
>   for its status to be upgraded.
> 
Thanks! Will try to add these sections.

> Also, it would be really good to have similar documents for the other
> PSR features we have upstream already (perhaps finding a way for not
> duplicating all the common information).
> 
Besides L2 CAT, there are L3 CAT and CDP features for allocation tech.
Also, there are CMT/MBM features for monitoring tech. We will discuss
these to check if we can add these feature documents step by step.

> Thanks and Regards,
> Dario
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Payed Xen Admin

[Thomas Toka]

Hello,

thanks for answering Neil. I think Neil means the block devices ?

Neil can you show us how to verify if those devices are still running for the 
null domain ids?

I also think its maybe just a timing problem, maybe they do not shut down 
always as they should..

We can give you surely access to such u box and you could have a look..

Mit freundlichen Grüßen

Thomas Toka

- Second Level Support -

[logo_mail]

IP-Projects GmbH & Co. KG
Am Vogelherd 14
D - 97295 Waldbrunn

Telefon: 09306 - 76499-0
FAX: 09306 - 76499-15
E-Mail: i...@ip-projects.de

Geschäftsführer: Michael Schinzel
Registergericht Würzburg: HRA 6798
Komplementär: IP-Projects Verwaltungs GmbH



Von: Michael Schinzel
Gesendet: Montag, 28. November 2016 18:20
An: Neil Sikka 
Cc: Xen-devel ; Thomas Toka 

Betreff: AW: [Xen-devel] Payed Xen Admin

Hello,

thank you for your response. There are no quemu prozesses which we can identify 
with the ID of the failed guest.


Mit freundlichen Grüßen

Michael Schinzel
- Geschäftsführer -

[https://www.ip-projects.de/logo_mail.png]

IP-Projects GmbH & Co. KG
Am Vogelherd 14
D - 97295 Waldbrunn

Telefon: 09306 - 76499-0
FAX: 09306 - 76499-15
E-Mail: i...@ip-projects.de

Geschäftsführer: Michael Schinzel
Registergericht Würzburg: HRA 6798
Komplementär: IP-Projects Verwaltungs GmbH



Von: Neil Sikka [mailto:neilsi...@gmail.com]
Gesendet: Montag, 28. November 2016 14:30
An: Michael Schinzel >
Cc: Xen-devel 
>
Betreff: Re: [Xen-devel] Payed Xen Admin


Usually, I've seen (null) domains are not running but their Qemu DMs are 
running. You could probably remove the (null) from the list by using "kill -9" 
on the qemu pids.

On Nov 27, 2016 11:55 PM, "Michael Schinzel" 
> wrote:
Good Morning,

we have some issues with our Xen Hosts. It seems it is a xen bug but we do not 
find the solution.

NameID   Mem VCPUs  State   Time(s)
Domain-0 0 16192 4 r-  147102.5
(null)   2 1 1 --p--d1273.2
vmanager2268 4  1024 1 -b   34798.8
vmanager2340 5  1024 1 -b5983.8
vmanager261912   512 1 -b1067.0
vmanager261813  1024 4 -b1448.7
vmanager255714  1024 1 -b2783.5
vmanager187116   512 1 -b3772.1
vmanager259217   512 1 -b   19744.5
vmanager256618  2048 1 -b3068.4
vmanager222819   512 1 -b 837.6
vmanager224120   512 1 -b 997.0
vmanager224421  2048 1 -b1457.9
vmanager227222  2048 1 -b1924.5
vmanager222623  1024 1 -b1454.0
vmanager224524   512 1 -b 692.5
vmanager224925   512 1 -b   22857.7
vmanager226526  2048 1 -b1388.1
vmanager227027   512 1 -b1250.6
vmanager227128  2048 3 -b2060.8
vmanager227329  1024 1 -b   34089.4
vmanager227430  2048 1 -b8585.1
vmanager228131  2048 2 -b1848.9
vmanager228232   512 1 -b 755.1
vmanager228833  1024 1 -b 543.6
vmanager229234   512 1 -b3004.9
vmanager204135   512 1 -b4246.2
vmanager221636  1536 1 -b   47508.3
vmanager229537   512 1 -b1414.9
vmanager259938  1024 4 -b7523.0
vmanager229639  1536 1 -b7142.0
vmanager229740   512 1 -b 536.7
vmanager213642  1024 1 -b6162.9
vmanager229843   512 1 -b 441.7
vmanager2299

Re: [Xen-devel] Wondering about cirris and stdvga

[Konrad Rzeszutek Wilk]

On Fri, Nov 25, 2016 at 07:17:31PM +0100, Dario Faggioli wrote:
> On Mon, 2016-11-21 at 10:04 +0100, Dario Faggioli wrote:
> > On Sat, 2016-11-19 at 12:56 +0200, Pasi Kärkkäinen wrote:
> > > 2) It'd good to create an upstream Wayland bugreport and
> > > investigate
> > > more about why cirrus is broken with Wayland.
> > > 
> > Sure, I can do that.
> > 
> An update.
> 
> The discussion here has gone on a bit:
> https://bugzilla.redhat.com/show_bug.cgi?id=1227770
> 
> The conclusion seems to be that:
> "cirrus (virtual) hardware is simply to old to run wayland."
> 
> And so this is (and will very likely remain) a 'WONTFIX' for cirrus, at
> least on Fedora.
> 
> I've also opened a thread on wayland-devel mailing list:
> https://lists.freedesktop.org/archives/wayland-devel/2016-November/0318
> 56.html
> 
> There, I learned that Wayland is not the component to blame, as Wayland
> is the protocol. So, in our case, the 'bug' is most likely in
> gnome-shell / Mutter.
> 
> That's not a good thing, though. In fact, just to cite a few sentences
> from the thread:
> 
> "Packed 24bpp is going to be pain, not least because I don't know of
> any clients which render in packed-24"
> 
> "The 24bpp paths in pretty much everything are also badly untested, so
> that's asking for trouble."
> 
> "you will need to test and fix every single Wayland compositor out
> there."
> 
> "I really think you'd be far far better off trying to figure out how to
> move off the legacy Cirrus emulation as soon as you can."
> 
> So, we can try seeing if I manage to get some logs out of Mutter to
> figure out the actual bug more precisely _but_, considering all that
> people have said both here and in the other forums, I think it would be
> better to spend that time figuring out how to switch (and document this
> for 4.8 and previous version, of course).

+1

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 01/15] docs: L2 Cache Allocation Technology (CAT) feature document.

[Yi Sun]

On 16-11-25 18:39:41, Dario Faggioli wrote:
> A couple of more things about this document...
> 
> On Tue, 2016-10-25 at 11:40 +0800, Yi Sun wrote:
> > diff --git a/docs/features/l2_cat.pandoc 
> >
> The name of the file could be a bit more descriptive. What about
> something like:
> 
> intel_psr_l2_cat.pandoc
> 
Thanks for your suggestion!

> > +## Implementation Description
> > +
> > +* Hypervisor interfaces:
> > +
> > +  1. Ext: Boot line parameter "psr=cat" now will enable L2 CAT and
> > L3
> > +  CAT if hardware supported.
> > +
> > +  2. New: SYSCTL:
> > +  - XEN_SYSCTL_PSR_CAT_get_l2_info: Get L2 CAT information.
> > +
> > +  3. New: DOMCTL:
> > +  - XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM: Get L2 CBM for a
> > domain.
> > +  - XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM: Set L2 CBM for a
> > domain.
> > +
> What do these 'Ext' and 'New' prefixes mean? You perhaps what to
> communicate whether you are extending something that was existing
> already, or introducing something new... Well, I don't think that is a
> very valuable piece of information.
> 
> After all, we want to know that there is a relevant boot parameter, a
> sysctl and a domctl interface, no matter whether they're new or not
> (especially considering that this is the first and for now only feature
> document for PSR).
> 
> I'd just kill them.
> 
Yes, your understand is correct. Thanks for your comments! I will kill them.

> > +* xl interfaces:
> > +
> > +  1. Ext: psr-cat-show -l2 domain-id
> > +  Show L2 cbm for a domain.
> > +  => XEN_SYSCTL_PSR_CAT_get_l2_info /
> > + XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM
> > +
> > +  2. Ext: psr-mba-set -l2 domain-id cbm
> > +  Set L2 cbm for a domain.
> > +  => XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM
> > +
> > +  3. Ext: psr-hwinfo
> > +  Show PSR HW information, including L2 CAT
> > +  => XEN_SYSCTL_PSR_CAT_get_l2_info
> > +
> Same here.
> 
Thank you!

> > +# User information
> > +
> > +* Feature Enabling:
> > +
> > +  Add "psr=cat" to boot line parameter to enable all supported level
> > CAT
> > +  features.
> > +
> > +* xl interfaces:
> > +
> > +  1. `psr-cat-show [OPTIONS] domain-id`:
> > +
> > + Show domain L2 or L3 CAT CBM.
> > +
> > + New option `-l` is added.
> > + `-l2`: Specify cbm for L2 cache.
> > + `-l3`: Specify cbm for L3 cache.
> > +
> > + If neither `-l2` nor `-l3` is given, level 3 is the default
> > option.
> > +
> Sorry for saying this only now, but wouldn't it be more natural, if
> neither -l2 not -l3 is specified, to show both (or, in general, all
> that is supported)?
> 
This is for backward compatibility. The original command only supports
L3 CAT and it does not have '-l' option.

But for show command, your suggestion is good. We can show both or
prompt user if any one is not supported.

> > +  2. `psr-cat-cbm-set [OPTIONS] domain-id cbm`:
> > +
> > + Set domain L2 or L3 CBM.
> > +
> > + New option `-l` is added.
> > + `-l2`: Specify cbm for L2 cache.
> > + `-l3`: Specify cbm for L3 cache.
> > +
> > + If neither `-l2` nor `-l3` is given, level 3 is the default
> > option.
> > +
> > +  3. `psr-hwinfo [OPTIONS]`:
> > +
> > + Show L2 & L3 CAT HW informations on every socket.
> 
> > +--
> > --
> > +Date   Revision Version  Notes
> > +--   -
> > --
> > +2016-08-12 1.0  Xen 4.7  Initial design
> > +2016-09-21 2.0  Xen 4.7  Changes according to review comments.
> > + 1. L2 CBM bits should be continuous
> > too.
> > + 2. Describe 'struct feat_info'
> > + 3. Update 'struct feat_list"
> > description.
> > + 4. Update 'struct feat_ops"
> > description.
> > + 5. Update `psr-cat-show` description.
> > + 6. Update `psr-cat-cbm-set`
> > description.
> > + 7. Add volume and chapter info in
> > References.
> >
> If you want to keep track of this uncommited version here, I think it's
> ok. But I'd just cur it short to a quick 1-liner summary and kill the
> detailed list of changes (which could then be moved in the patch
> changelog, but below the usual '---' so it won't get commited).
> 
> Personally, I'd also, avoid specifying any Xen version in for these,
> and do that starting from the line corresponding to the first version
> of the document that hits the tree. Like this, it somehow gives the
> impression that the feature is present in Xen 4.7, which is not true.
> 
> Regards,
> Dario

Thanks a lot for the suggestion! I will remove Xen version and change
log here.

BRs,
Sun Yi

> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software 

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

[Dongli Zhang]

2016-11-25 5:10 GMT+08:00 Volodymyr Babchuk :
> Hello all,

Hi Volodymyr!

>
> My name is Volodymyr Babchuk, I'm working on EPAM Systems with bunch
> of other guys like Artem Mygaiev or Andrii Anisov. My responsibility
> there is security in embedded systems.
>
> I would like to discuss approaches to OP-TEE support in XEN.
> But first small introduction for those who is not familiar with topic:
>
> There are such thing as Security Extensions for ARM cores. It is part
> of bigger thing - ARM TrustZone. Security extensions allows CPU to
> work in two states: Normal (Non-Secure) and Secure.
> Other parts of TrustZone provide hardware protection for peripherals,
> memory regions, etc. So, when CPU is running in secure state, it have
> access to all peripherals and memories, also it can forbid access to
> some of those resources from Normal state. Secure state have own
> Supervisor and User modes, so we can run OS there.
> Just to be clear, CPU can run in following modes; user, supervisor,
> hypervisor, secure monitor, secure user and secure supervisor. Last
> two basically are the same as normal USR and SVC, but in secure state.
> And Secure Monitor is special mode, that can switch Secure state to
> Non-secure state and back. SMC instruction takes into this mode.
> So, we can run one OS in secure state and one in non-secure state.
> They will be mostly independent from each other. In normal
> (non-secure) mode we run, say, Linux. And in Secure mode we run some
> Trusted OS (or Secure Os). Secure OS provides services like
> cryptography, secure storage, DRM, virtual SIM, etc. to Normal world
> OS (it also called "Rich OS". It can be Linux for example.).
> There are standard created by GlobalPlatform that is called "Trusted
> Execution Environment" (TEE). It defines requirements and APIs for the
> Secure OS. There are number number of Secure OSes that tries to be
> conform with TEE specification and OP-TEE is one of them.
>
> CPU is normally running in Non-Secure state. When normal world OS
> needs some services from Secure OS, it issues SMC instruction with
> command data. This instruction puts processor into Secure Monitor
> Mode, where secure monitor code examines request. If it is request to
> Secure OS, it switches processor to Secure Supervisor mode and passes
> request to Secure OS. When Secure OS finishes work, it also issues SMC
> instruction and Secure Monitor switches processor back to non-secure
> state, returning control to Rich OS.
> SMC instruction can be used not only to communicate with SecureOS, but
> also for other services like power control, control of processor
> cores, etc. ARM wrote document "SMC Calling Convention" which in
> detail describes how this instruction can be used.  By the way, SMCCC
> requires to pass Virtual Machine ID in one of the registers during SMC
> call.

Would you please explain the objective of the project? We use Trustzone on
smartphone because we do not trust the OS kernel and we prefer to protect the
integrity and privacy of execution/data with hardware. Actually, this can be
achieved with ARM virtualization as well. Trustzone is preferred because ARM
virtualization based protection is not hardware based.

Would you like to run unmodified software in richos so GlobalPlatform API would
be supported?  Who would be in the TCB? Only OP-TEE OS? OP-TEE OS and xen
hypervisor? Or all of OP-TEE OS, xen hypervisor and dom0? To clarify my
question, who will be in secure world and who will be in normal world in your
design?

Per my understanding, TCB consists of both OP-TEE OS and xen.

In which scenario this project will run? Are you going to provide
GlobalPlatform API in cloud environment or in embeded environment running
virtualization software?

Are you going to run OP-TEE OS as a guest domain or to run OP-TEE OS in
parallel to xen hypervisor? (e.g., OP-TEE OS in secure world and xen/dom0/domU
as a whole in normal world)

Sorry for my those many questions :)

>
> Now let's get back to XEN. We want XEN to provide TEE services to Dom0
> and guests. I can see different approaches to this:
>
>  - One of them I call "Emulated TEE". Guests does not have access to
> real TEE OS. Instead somewhere (in Dom0) we run instance of TEE for
> each of the Guests. This provides perfect isolation, as TEE instances
> does not anything about each one. But we will miss all hardware
> benefits like cryptographic acceleration.
>  - Another way is to allow guests to work with real TEE running Secure
> state. In this case TEE should be aware about guests to track shared
> memories, opened sessions, etc. It requires some careful programming
> to ensure that guest belongings are isolated from each other. But as
> reward we are much closer to original TrustZone desing.
>
> Personally I prefer second approach. I, even, did small PoC that
> allows different guests to work with OP-TEE (but not simultaneously!).
> You can find patches at [1] if you are interested.
> During 

Re: [Xen-devel] [PATCH v3 04/15] x86: refactor psr: Encapsulate 'cbm_len' and 'cbm_max'

[Yi Sun]

On 16-11-25 09:57:31, Jan Beulich wrote:
> >>> On 25.11.16 at 17:27,  wrote:
>  On 25.10.16 at 05:40,  wrote:
> >> 'cbm_len' and 'cbm_max' are CAT/CDP specific feature HW info.
> >> So encapsulate them into 'struct psr_cat_hw_info'. If new
> >> feature is supported, we can define other structure to save
> >> its HW info.
> > 
> > Part of my problem following you here is that you talk about
> > cbm_max, but the code changes cos_max, which so far I had
> > understood would be a generic limit,
> 
> So I've gone and looked back at patch 1, where indeed you say
> the limits might differ. Which raises the question then what
> opt_cos_max is representing.
> 
> Having seen v1, v2, and v3 up to patch 5 I start wondering
> whether the whole current code wouldn't better be ripped out
> and then be replaced by something written from scratch. That's
> because the split, while having reduced individual patch size,
> doesn't really make the whole thing much better reviewable.
> And the original implementation apparently simply didn't have
> in mind how future additions on the hardware side could look
> like.
> 
> Thoughts?
> 
> Jan

Firstly, I want to say sorry that the V3 still does not make you
feel good. I planned to split the big patch based on data structure
changes to make you understand more easily.

The original implementation of psr.c does not consider much about
future features because there was only L3 CAT introduced and we do
not know there will be new features and how they work. That is the
reason I refactor the psr.c to make it be easy to add new features
by abstracting the common things.

To make codes be better reviewable, I propose below three suggestions:
1) I write a design document about refactor to make you more easily 
understand the ideas.
2) Replace the psr.c with a new file which discards all old codes so
that you do not need to consider old implementations which may cause
confusion.
3) Discard the refactor codes. Just implement L2 CAT based on current
codes. Because L2 CAT does not have much difference with L3.

How do you think? If you can offer your ideas to design and implement
the codes, that would be a great opportunity for me to learn! Thank you!

BRs,
Sun Yi

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [ler...@redhat.com: Re: [PATCH v3] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier]

[Wei Liu]

On Fri, Nov 25, 2016 at 12:04:05PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 25, 2016 at 01:51:56PM +, Wei Liu wrote:
> > On Fri, Nov 25, 2016 at 08:24:00AM -0500, Konrad Rzeszutek Wilk wrote:
> > > Hey Wei, Anthony,
> > > 
> > > Are you guys OK pushing this commit: 2667ad40919a in the
> > > git://xenbits.xen.org/ovmf.git 
> > > 
> > > tree? Without this I cannot build Xen 4.8 with TianoCore
> > > (--enable-ovmf).
> > > 
> > 
> > We normally don't deviate from upstream. We would need to wait for this
> > to pass osstest pushgate, and then update Config.mk.
> 
> I see. We seem to be 791 commits behind upstream? Oh, and 770
> to catch up with 2667ad40919a. Yikes.
> 

I see that commit has passed our pushgate. I will see what I can do.

In any case, because OVMF is still experimental and disabled by default,
we used to update the commit id in stable branches as well. So they will
get the latest commit at the end.

Or you can provide a custom tree when building Xen. There isn't really
anything that would tie OVMF to a specific version of Xen -- at least
not for now.

What is even better is that you can provide a OVMF binary direct via
toolstack in this release.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 1/2] xen_platform: unplug also SCSI disks

[Wei Liu]

On Mon, Nov 28, 2016 at 10:28:21AM -0800, Stefano Stabellini wrote:
> On Thu, 24 Nov 2016, Olaf Hering wrote:
> > On Fri, Oct 21, Olaf Hering wrote:
> > 
> > > Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can
> > > be used by the emulated BIOS to boot from disk. If the HVM domU has also
> > > PV driver the disk may appear twice in the guest. To avoid this an
> > > unplug of the emulated hardware is needed, similar to what is done for
> > > IDE and NIC drivers already.
> > 
> > How are these patches supposed to find their way into
> > qemu-xen.git#staging? Do I have to wait until #staging gets updated to
> > qemu-2.8+ at some point, or would you please cherry-pick these two commits:
> > 
> > 3513201 xen_platform: SUSE xenlinux unplug for emulated PCI
> > 78f6689 xen_platform: unplug also SCSI disks
> 
> Anthony, are you going to take care of this?
> However, given the state of the release, they'll need a release-ack to
> be applied.

I think these patches will need to wait to be backported after 4.8 is
released.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.5-testing test] 102699: regressions - FAIL

[osstest service owner]

flight 102699 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102699/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 102692 REGR. vs. 
99725

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 14 guest-saverestore.2 fail in 102680 pass in 
102699
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
102680 pass in 102699
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail in 102692 pass in 102699
 test-amd64-i386-libvirt 14 guest-saverestore fail in 102692 pass in 102699
 test-armhf-armhf-libvirt-raw 9 debian-di-install fail in 102692 pass in 102699
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 102692 
pass in 102699
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
102680
 test-armhf-armhf-libvirt 11 guest-startfail pass in 102692

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 99725
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail in 102680 like 99725
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 102692 blocked in 
99725
 test-armhf-armhf-xl-rtds 11 guest-start  fail in 102692 like 99725
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 99725

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt12 migrate-support-check fail in 102692 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass

version targeted for testing:
 qemuu37a460ca696381bb14dfbf012d7a062c7c05c324
baseline version:
 qemuu835c204f1196ab8f5213a9dc5299ed76e748cdca

Last test of basis99725  2016-07-27 18:10:31 Z  124 days
Testing same since   102533  2016-11-22 20:11:10 Z6 days   11 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 

[Xen-devel] [PATCH] arm/acpi: hide watchdog timer in GTDT table for dom0

[Shanker Donthineni]

Either we have to hide the watchdog timer section in GTDT or emulate
watchdog timer block for dom0. Otherwise, system gets panic when
dom0 accesses its MMIO registers. The current XEN doesn't support
virtualization of watchdog timer, so hide the watchdog timer section
for dom0.

Signed-off-by: Shanker Donthineni 
---
 xen/arch/arm/domain_build.c | 41 +
 xen/include/asm-arm/acpi.h  |  1 +
 2 files changed, 42 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e8a400c..611c803 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1668,6 +1668,8 @@ static int acpi_create_xsdt(struct domain *d, struct 
membank tbl_add[])
ACPI_SIG_FADT, tbl_add[TBL_FADT].start);
 acpi_xsdt_modify_entry(xsdt->table_offset_entry, entry_count,
ACPI_SIG_MADT, tbl_add[TBL_MADT].start);
+acpi_xsdt_modify_entry(xsdt->table_offset_entry, entry_count,
+   ACPI_SIG_GTDT, tbl_add[TBL_GTDT].start);
 xsdt->table_offset_entry[entry_count] = tbl_add[TBL_STAO].start;
 
 xsdt->header.length = table_size;
@@ -1718,6 +1720,41 @@ static int acpi_create_stao(struct domain *d, struct 
membank tbl_add[])
 return 0;
 }
 
+static int acpi_create_gtdt(struct domain *d, struct membank tbl_add[])
+{
+struct acpi_table_header *table = NULL;
+struct acpi_table_gtdt *gtdt = NULL;
+u32 table_size = sizeof(struct acpi_table_gtdt);
+u32 offset = acpi_get_table_offset(tbl_add, TBL_GTDT);
+acpi_status status;
+u8 *base_ptr, checksum;
+
+status = acpi_get_table(ACPI_SIG_GTDT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+printk("Failed to get GTDT table, %s\n", msg);
+return -EINVAL;
+}
+
+base_ptr = d->arch.efi_acpi_table + offset;
+ACPI_MEMCPY(base_ptr, table, sizeof(struct acpi_table_gtdt));
+
+gtdt = (struct acpi_table_gtdt *)base_ptr;
+gtdt->header.length = table_size;
+gtdt->platform_timer_count = 0;
+gtdt->platform_timer_offset = table_size;
+checksum = acpi_tb_checksum(ACPI_CAST_PTR(u8, gtdt), table_size);
+gtdt->header.checksum -= checksum;
+
+tbl_add[TBL_GTDT].start = d->arch.efi_acpi_gpa + offset;
+tbl_add[TBL_GTDT].size = table_size;
+
+return 0;
+}
+
 static int acpi_create_madt(struct domain *d, struct membank tbl_add[])
 {
 struct acpi_table_header *table = NULL;
@@ -1909,6 +1946,10 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 if ( rc != 0 )
 return rc;
 
+rc = acpi_create_gtdt(d, tbl_add);
+if ( rc != 0 )
+return rc;
+
 rc = acpi_create_xsdt(d, tbl_add);
 if ( rc != 0 )
 return rc;
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 9f954d3..214511c 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -36,6 +36,7 @@ typedef enum {
 TBL_FADT,
 TBL_MADT,
 TBL_STAO,
+TBL_GTDT,
 TBL_XSDT,
 TBL_RSDP,
 TBL_EFIT,
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.5-testing test] 102698: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 102698 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102698/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101275

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   3 host-install(3)  broken pass in 102690
 test-amd64-amd64-xl-multivcpu  9 debian-install  fail in 102690 pass in 102698
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 102690 
pass in 102698
 test-amd64-amd64-migrupgrade 20 guest-start/debian fail pass in 102690
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 102690

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt   15 guest-start/debian.repeat fail blocked in 101275
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 102690 like 
101258
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 101275
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101275
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail like 
101275
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101275
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 101275
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101275
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101275

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2 18 xtf/test-hvm32-cpuid-faulting fail in 102690 never 
pass
 test-xtf-amd64-amd64-2 27 xtf/test-hvm32pae-cpuid-faulting fail in 102690 
never pass
 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pse-cpuid-faulting fail in 102690 
never pass
 test-xtf-amd64-amd64-2 37 xtf/test-hvm64-cpuid-faulting fail in 102690 never 
pass
 test-xtf-amd64-amd64-2 49 xtf/test-pv32pae-cpuid-faulting fail in 102690 never 
pass
 test-xtf-amd64-amd64-2 57 xtf/test-pv64-cpuid-faulting fail in 102690 never 
pass
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 102690 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 102690 never 
pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 102690 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 102690 never pass
 test-xtf-amd64-amd64-5   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-3  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-3   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-4 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-4 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 

Re: [Xen-devel] [PATCH v2 17/19] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, November 28, 2016 7:14 PM
> 
> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
> to inject the pagefault themselves.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Kevin Tian 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.7-testing test] 102697: regressions - FAIL

[osstest service owner]

flight 102697 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102697/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
100711
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 102689 REGR. 
vs. 100711

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  6 xen-boot   fail pass in 102689

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100711

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 102689 never pass
 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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuue27a2f17bc2d9d7f8afce2c5918f4f23937b268e
baseline version:
 qemuue927b5f5a809f07b73b063831527c8a87f053933

Last test of basis   100711  2016-09-02 02:46:43 Z   87 days
Testing same since   102532  2016-11-22 20:11:32 Z6 days   10 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 

[Xen-devel] [ovmf baseline-only test] 68116: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68116 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68116/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf bb767506b265b1cdbf0dbec58c9a3f4c6be6ab2b
baseline version:
 ovmf 4e3b05a49f454bc257252ae9090421e3c8447737

Last test of basis68114  2016-11-28 14:19:32 Z0 days
Testing same since68116  2016-11-28 20:21:13 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit bb767506b265b1cdbf0dbec58c9a3f4c6be6ab2b
Author: Laszlo Ersek 
Date:   Thu Nov 24 20:49:43 2016 +0100

UefiCpuPkg/PiSmmCpuDxeSmm: handle dynamic PcdCpuMaxLogicalProcessorNumber

"UefiCpuPkg/UefiCpuPkg.dec" already allows platforms to make
PcdCpuMaxLogicalProcessorNumber dynamic, however PiSmmCpuDxeSmm does not
take this into account everywhere. As soon as a platform turns the PCD
into a dynamic one, at least S3 fails. When the PCD is dynamic, all
PcdGet() calls translate into PCD DXE protocol calls, which are only
permitted at boot time, not at runtime or during S3 resume.

We already have a variable called mMaxNumberOfCpus; it is initialized in
the entry point function like this:

> //
> // If support CPU hot plug, we need to allocate resources for possibly
> // hot-added processors
> //
> if (FeaturePcdGet (PcdCpuHotPlugSupport)) {
>   mMaxNumberOfCpus = PcdGet32 (PcdCpuMaxLogicalProcessorNumber);
> } else {
>   mMaxNumberOfCpus = mNumberOfCpus;
> }

There's another use of the PCD a bit higher up, also in the entry point
function:

> //
> // Use MP Services Protocol to retrieve the number of processors and
> // number of enabled processors
> //
> Status = MpServices->GetNumberOfProcessors (MpServices, ,
>);
> ASSERT_EFI_ERROR (Status);
> ASSERT (mNumberOfCpus <= PcdGet32 (PcdCpuMaxLogicalProcessorNumber));

Preserve these calls in the entry point function, and replace all other
uses of PcdCpuMaxLogicalProcessorNumber -- there are only reads -- with
mMaxNumberOfCpus.

For PcdCpuHotPlugSupport==TRUE, this is an unobservable change.

For PcdCpuHotPlugSupport==FALSE, we even save SMRAM, because we no longer
allocate resources needlessly for CPUs that can never appear in the
system.

PcdCpuMaxLogicalProcessorNumber is also retrieved in
"UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c",  but only in
the library instance constructor, which runs even before the entry point
function is called.

Cc: Igor Mammedov 
Cc: Jeff Fan 
Cc: Jordan Justen 
Cc: Michael Kinney 
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=116
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jeff Fan 

commit 520150302c6ee3a4809f00c25dc3b597334d96ef
Author: Star Zeng 
Date:   Fri Nov 25 10:38:02 2016 +0800

SecurityPkg Tcg2ConfigDxe: Align Attempt TPM Device help with options

Current options only have TPM 1.2 and TPM 2.0,
but help shows Disable, TPM1.2, or TPM2.0,
they are mismatched.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

[Xen-devel] [xen-unstable test] 102695: tolerable FAIL - PUSHED

[osstest service owner]

flight 102695 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102695/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 102686
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 102686
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102686
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102686
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102686
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 102686
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102686
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102686
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 102686

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  99a10da1b4fee8ef7a096e5fd3608f6c15932eb0
baseline version:
 xen  1c524dd494019bc98e23075dcdba11c8e6add017

Last test of basis   102686  2016-11-28 01:57:43 Z0 days
Testing same since   102695  2016-11-28 12:45:33 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 

[Xen-devel] [PATCH v2 2/4] 9pfs: introduce transport specific callbacks

[Stefano Stabellini]

Don't call virtio functions from 9pfs generic code, use generic function
callbacks instead.

Signed-off-by: Stefano Stabellini 

---
Changes in v2:
- constify virtio_9p_transport and V9fsTransport
- assert !s->transport.
- code style
---
 hw/9pfs/9p.c   |  8 
 hw/9pfs/9p.h   | 19 +++
 hw/9pfs/virtio-9p-device.c | 24 +---
 hw/9pfs/virtio-9p.h|  9 -
 4 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 05e950f..5a20a13 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -47,7 +47,7 @@ ssize_t pdu_marshal(V9fsPDU *pdu, size_t offset, const char 
*fmt, ...)
 va_list ap;
 
 va_start(ap, fmt);
-ret = virtio_pdu_vmarshal(pdu, offset, fmt, ap);
+ret = pdu->s->transport->pdu_vmarshal(pdu, offset, fmt, ap);
 va_end(ap);
 
 return ret;
@@ -59,7 +59,7 @@ ssize_t pdu_unmarshal(V9fsPDU *pdu, size_t offset, const char 
*fmt, ...)
 va_list ap;
 
 va_start(ap, fmt);
-ret = virtio_pdu_vunmarshal(pdu, offset, fmt, ap);
+ret = pdu->s->transport->pdu_vunmarshal(pdu, offset, fmt, ap);
 va_end(ap);
 
 return ret;
@@ -67,7 +67,7 @@ ssize_t pdu_unmarshal(V9fsPDU *pdu, size_t offset, const char 
*fmt, ...)
 
 static void pdu_push_and_notify(V9fsPDU *pdu)
 {
-virtio_9p_push_and_notify(pdu);
+pdu->s->transport->push_and_notify(pdu);
 }
 
 static int omode_to_uflags(int8_t mode)
@@ -1751,7 +1751,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, 
V9fsPDU *pdu,
 struct iovec *iov;
 unsigned int niov;
 
-virtio_init_iov_from_pdu(pdu, , , is_write);
+pdu->s->transport->init_iov_from_pdu(pdu, , , is_write);
 
 qemu_iovec_init_external(, iov, niov);
 qemu_iovec_init(qiov, niov);
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index 07cee01..c8c9aa8 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -230,6 +230,7 @@ typedef struct V9fsState
 enum p9_proto_version proto_version;
 int32_t msize;
 V9fsPDU pdus[MAX_REQ];
+const struct V9fsTransport *transport;
 /*
  * lock ensuring atomic path update
  * on rename.
@@ -343,4 +344,22 @@ void pdu_free(V9fsPDU *pdu);
 void pdu_submit(V9fsPDU *pdu);
 void v9fs_reset(V9fsState *s);
 
+struct V9fsTransport {
+ssize_t (*pdu_vmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt,
+va_list ap);
+ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt,
+  va_list ap);
+void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov,
+ unsigned int *pniov, bool is_write);
+void(*push_and_notify)(V9fsPDU *pdu);
+};
+
+static inline int v9fs_register_transport(V9fsState *s,
+const struct V9fsTransport *t)
+{
+assert(!s->transport);
+s->transport = t;
+return 0;
+}
+
 #endif
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 1782e4a..273425b 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -20,7 +20,9 @@
 #include "hw/virtio/virtio-access.h"
 #include "qemu/iov.h"
 
-void virtio_9p_push_and_notify(V9fsPDU *pdu)
+static const struct V9fsTransport virtio_9p_transport;
+
+static void virtio_9p_push_and_notify(V9fsPDU *pdu)
 {
 V9fsState *s = pdu->s;
 V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
@@ -126,6 +128,7 @@ static void virtio_9p_device_realize(DeviceState *dev, 
Error **errp)
 v->config_size = sizeof(struct virtio_9p_config) + strlen(s->fsconf.tag);
 virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size);
 v->vq = virtio_add_queue(vdev, MAX_REQ, handle_9p_output);
+v9fs_register_transport(s, _9p_transport);
 
 out:
 return;
@@ -148,8 +151,8 @@ static void virtio_9p_reset(VirtIODevice *vdev)
 v9fs_reset(>state);
 }
 
-ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset,
-const char *fmt, va_list ap)
+static ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset,
+   const char *fmt, va_list ap)
 {
 V9fsState *s = pdu->s;
 V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
@@ -158,8 +161,8 @@ ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset,
 return v9fs_iov_vmarshal(elem->in_sg, elem->in_num, offset, 1, fmt, ap);
 }
 
-ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset,
-  const char *fmt, va_list ap)
+static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset,
+ const char *fmt, va_list ap)
 {
 V9fsState *s = pdu->s;
 V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
@@ -168,8 +171,8 @@ ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset,
 return v9fs_iov_vunmarshal(elem->out_sg, elem->out_num, offset, 1, fmt, 
ap);
 }
 
-void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec 

[Xen-devel] [PATCH v2 1/4] 9pfs: move pdus to V9fsState

[Stefano Stabellini]

pdus are initialized and used in 9pfs common code. Move the array from
V9fsVirtioState to V9fsState.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 
---
 hw/9pfs/9p.c| 7 +++
 hw/9pfs/9p.h| 1 +
 hw/9pfs/virtio-9p.h | 1 -
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index aea7e9d..05e950f 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3440,7 +3440,6 @@ void pdu_submit(V9fsPDU *pdu)
 /* Returns 0 on success, 1 on failure. */
 int v9fs_device_realize_common(V9fsState *s, Error **errp)
 {
-V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
 int i, len;
 struct stat stat;
 FsDriverEntry *fse;
@@ -3451,9 +3450,9 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp)
 QLIST_INIT(>free_list);
 QLIST_INIT(>active_list);
 for (i = 0; i < (MAX_REQ - 1); i++) {
-QLIST_INSERT_HEAD(>free_list, >pdus[i], next);
-v->pdus[i].s = s;
-v->pdus[i].idx = i;
+QLIST_INSERT_HEAD(>free_list, >pdus[i], next);
+s->pdus[i].s = s;
+s->pdus[i].idx = i;
 }
 
 v9fs_path_init();
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index 3976b7f..07cee01 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -229,6 +229,7 @@ typedef struct V9fsState
 char *tag;
 enum p9_proto_version proto_version;
 int32_t msize;
+V9fsPDU pdus[MAX_REQ];
 /*
  * lock ensuring atomic path update
  * on rename.
diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index 25c47c7..52c4b9d 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -10,7 +10,6 @@ typedef struct V9fsVirtioState
 VirtIODevice parent_obj;
 VirtQueue *vq;
 size_t config_size;
-V9fsPDU pdus[MAX_REQ];
 VirtQueueElement *elems[MAX_REQ];
 V9fsState state;
 } V9fsVirtioState;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 4/4] 9pfs: introduce init_out/in_iov_from_pdu

[Stefano Stabellini]

Not all 9pfs transports share memory between request and response. For
those who don't, it is necessary to know how much memory is required in
the response.

Split the existing init_iov_from_pdu function in two:
init_out_iov_from_pdu (for writes) and init_in_iov_from_pdu (for reads).
init_in_iov_from_pdu takes an additional size parameter to specify the
memory required for the response message.

Signed-off-by: Stefano Stabellini 
---
 hw/9pfs/9p.c   |  6 +-
 hw/9pfs/9p.h   |  6 --
 hw/9pfs/virtio-9p-device.c | 28 ++--
 3 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 79d7201..ce1f9d9 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1652,7 +1652,11 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, 
V9fsPDU *pdu,
 struct iovec *iov;
 unsigned int niov;
 
-pdu->s->transport->init_iov_from_pdu(pdu, , , is_write);
+if (is_write) {
+pdu->s->transport->init_out_iov_from_pdu(pdu, , );
+} else {
+pdu->s->transport->init_in_iov_from_pdu(pdu, , , size);
+}
 
 qemu_iovec_init_external(, iov, niov);
 qemu_iovec_init(qiov, niov);
diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index c8c9aa8..4c4feaf 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -349,8 +349,10 @@ struct V9fsTransport {
 va_list ap);
 ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt,
   va_list ap);
-void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov,
- unsigned int *pniov, bool is_write);
+void(*init_in_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov,
+unsigned int *pniov, size_t size);
+void(*init_out_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov,
+ unsigned int *pniov);
 void(*push_and_notify)(V9fsPDU *pdu);
 };
 
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 273425b..27a4a32 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -171,26 +171,34 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t 
offset,
 return v9fs_iov_vunmarshal(elem->out_sg, elem->out_num, offset, 1, fmt, 
ap);
 }
 
-static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
- unsigned int *pniov, bool is_write)
+/* The size parameter is used by other transports. Do not drop it. */
+static void virtio_init_in_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
+unsigned int *pniov, size_t size)
 {
 V9fsState *s = pdu->s;
 V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
 VirtQueueElement *elem = v->elems[pdu->idx];
 
-if (is_write) {
-*piov = elem->out_sg;
-*pniov = elem->out_num;
-} else {
-*piov = elem->in_sg;
-*pniov = elem->in_num;
-}
+*piov = elem->in_sg;
+*pniov = elem->in_num;
+}
+
+static void virtio_init_out_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
+ unsigned int *pniov)
+{
+V9fsState *s = pdu->s;
+V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
+VirtQueueElement *elem = v->elems[pdu->idx];
+
+*piov = elem->out_sg;
+*pniov = elem->out_num;
 }
 
 static const struct V9fsTransport virtio_9p_transport = {
 .pdu_vmarshal = virtio_pdu_vmarshal,
 .pdu_vunmarshal = virtio_pdu_vunmarshal,
-.init_iov_from_pdu = virtio_init_iov_from_pdu,
+.init_in_iov_from_pdu = virtio_init_in_iov_from_pdu,
+.init_out_iov_from_pdu = virtio_init_out_iov_from_pdu,
 .push_and_notify = virtio_9p_push_and_notify,
 };
 
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 3/4] 9pfs: call v9fs_init_qiov_from_pdu before v9fs_pack

[Stefano Stabellini]

v9fs_xattr_read should not access VirtQueueElement elems directly.
Move v9fs_init_qiov_from_pdu up in the file and call
v9fs_init_qiov_from_pdu before v9fs_pack. Use v9fs_pack on the new
iovec.

Signed-off-by: Stefano Stabellini 

---
Changes in v2:
- add a call to qemu_iovec_destroy
- fix commit description
---
 hw/9pfs/9p.c | 59 ++-
 1 file changed, 30 insertions(+), 29 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 5a20a13..79d7201 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -1633,14 +1633,39 @@ out_nofid:
 pdu_complete(pdu, err);
 }
 
+/*
+ * Create a QEMUIOVector for a sub-region of PDU iovecs
+ *
+ * @qiov:   uninitialized QEMUIOVector
+ * @skip:   number of bytes to skip from beginning of PDU
+ * @size:   number of bytes to include
+ * @is_write:   true - write, false - read
+ *
+ * The resulting QEMUIOVector has heap-allocated iovecs and must be cleaned up
+ * with qemu_iovec_destroy().
+ */
+static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu,
+size_t skip, size_t size,
+bool is_write)
+{
+QEMUIOVector elem;
+struct iovec *iov;
+unsigned int niov;
+
+pdu->s->transport->init_iov_from_pdu(pdu, , , is_write);
+
+qemu_iovec_init_external(, iov, niov);
+qemu_iovec_init(qiov, niov);
+qemu_iovec_concat(qiov, , skip, size);
+}
+
 static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp,
uint64_t off, uint32_t max_count)
 {
 ssize_t err;
 size_t offset = 7;
 uint64_t read_count;
-V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
-VirtQueueElement *elem = v->elems[pdu->idx];
+QEMUIOVector qiov_full;
 
 if (fidp->fs.xattr.len < off) {
 read_count = 0;
@@ -1656,9 +1681,11 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, 
V9fsFidState *fidp,
 }
 offset += err;
 
-err = v9fs_pack(elem->in_sg, elem->in_num, offset,
+v9fs_init_qiov_from_pdu(_full, pdu, 0, read_count, false);
+err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset,
 ((char *)fidp->fs.xattr.value) + off,
 read_count);
+qemu_iovec_destroy(_full);
 if (err < 0) {
 return err;
 }
@@ -1732,32 +1759,6 @@ static int coroutine_fn 
v9fs_do_readdir_with_stat(V9fsPDU *pdu,
 return count;
 }
 
-/*
- * Create a QEMUIOVector for a sub-region of PDU iovecs
- *
- * @qiov:   uninitialized QEMUIOVector
- * @skip:   number of bytes to skip from beginning of PDU
- * @size:   number of bytes to include
- * @is_write:   true - write, false - read
- *
- * The resulting QEMUIOVector has heap-allocated iovecs and must be cleaned up
- * with qemu_iovec_destroy().
- */
-static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu,
-size_t skip, size_t size,
-bool is_write)
-{
-QEMUIOVector elem;
-struct iovec *iov;
-unsigned int niov;
-
-pdu->s->transport->init_iov_from_pdu(pdu, , , is_write);
-
-qemu_iovec_init_external(, iov, niov);
-qemu_iovec_init(qiov, niov);
-qemu_iovec_concat(qiov, , skip, size);
-}
-
 static void coroutine_fn v9fs_read(void *opaque)
 {
 int32_t fid;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 0/4] 9pfs: clean-up for multiple transports

[Stefano Stabellini]

Hi all,

this small patch series provides a few fixes and clean-ups in
preparation for the introduction of a 9pfs Xen transport.

Changes in v2:
- constify virtio_9p_transport and V9fsTransport
- assert !s->transport.
- code style
- add a call to qemu_iovec_destroy
- fix commit description of patch #3
- introduce init_out/in_iov_from_pdu


Stefano Stabellini (4):
  9pfs: move pdus to V9fsState
  9pfs: introduce transport specific callbacks
  9pfs: use v9fs_init_qiov_from_pdu instead of v9fs_pack
  9pfs: introduce init_out/in_iov_from_pdu

 hw/9pfs/9p.c   | 76 --
 hw/9pfs/9p.h   | 22 ++
 hw/9pfs/virtio-9p-device.c | 46 +++-
 hw/9pfs/virtio-9p.h| 10 --
 4 files changed, 94 insertions(+), 60 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/4] 9pfs: add a size parameter to init_iov_from_pdu

[Stefano Stabellini]

On Thu, 24 Nov 2016, Greg Kurz wrote:

> On Mon, 21 Nov 2016 13:39:32 -0800
> Stefano Stabellini  wrote:
> 
> > Not all 9pfs transports share memory between request and response. For
> > those who don't, it is necessary to know how much memory is required in
> > the response.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> 
> IIUC the transport used in Xen requires you pass the size when sending a
> P9_RREAD message back to the guest, i.e. only in the case when is_write is
> false, correct ?

That's right


> If so, for better clarity, what about having two distinct init_in_iov_from_pdu
> and init_out_iov_from_pdu ops, with an explicit comment in the virtio-9p
> implementation of init_in_iov_from_pdu so that someone isn't tempted to drop
> the apparently unused size argument ? Would this be ok for you on the Xen
> side ?

Sure, that's fine by me. I'll do that.


> Cheers.
> 
> --
> Greg
> 
> >  hw/9pfs/9p.c   | 2 +-
> >  hw/9pfs/9p.h   | 2 +-
> >  hw/9pfs/virtio-9p-device.c | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > index b6ec042..b82212b 100644
> > --- a/hw/9pfs/9p.c
> > +++ b/hw/9pfs/9p.c
> > @@ -1652,7 +1652,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector 
> > *qiov, V9fsPDU *pdu,
> >  struct iovec *iov;
> >  unsigned int niov;
> >  
> > -pdu->s->transport->init_iov_from_pdu(pdu, , , is_write);
> > +pdu->s->transport->init_iov_from_pdu(pdu, , , is_write, skip 
> > + size);
> >  
> >  qemu_iovec_init_external(, iov, niov);
> >  qemu_iovec_init(qiov, niov);
> > diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
> > index ab398d0..c830188 100644
> > --- a/hw/9pfs/9p.h
> > +++ b/hw/9pfs/9p.h
> > @@ -348,7 +348,7 @@ struct V9fsTransport {
> >  ssize_t (*pdu_vmarshal)(V9fsPDU *pdu, size_t offset, const char 
> > *fmt, va_list ap);
> >  ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char 
> > *fmt, va_list ap);
> >  void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov,
> > -  unsigned int *pniov, bool is_write);
> > +  unsigned int *pniov, bool is_write, size_t 
> > size);
> >  void(*push_and_notify)(V9fsPDU *pdu);
> >  };
> >  
> > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> > index e1a37a4..e2b27e8 100644
> > --- a/hw/9pfs/virtio-9p-device.c
> > +++ b/hw/9pfs/virtio-9p-device.c
> > @@ -172,7 +172,7 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, 
> > size_t offset,
> >  }
> >  
> >  static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov,
> > -  unsigned int *pniov, bool is_write)
> > +  unsigned int *pniov, bool is_write, size_t 
> > size)
> >  {
> >  V9fsState *s = pdu->s;
> >  V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Payed Xen Admin

[Neil Sikka]

My technique has been to look through top or ps on Dom0 for the QEMU
processes and correlate those PIDs with what I see in /proc/PID. The
proc/PID/cmdline file specifies which domid the QEMU process is doing the
device emulation for. If QEMU instances are running, try killing the QEMU
processes that are running for Domains that are destroyed.

On Mon, Nov 28, 2016 at 1:27 PM, Thomas Toka  wrote:

> Hello,
>
>
>
> thanks for answering Neil. I think Neil means the block devices ?
>
>
>
> Neil can you show us how to verify if those devices are still running for
> the null domain ids?
>
>
>
> I also think its maybe just a timing problem, maybe they do not shut down
> always as they should..
>
>
>
> We can give you surely access to such u box and you could have a look..
>
>
>
> Mit freundlichen Grüßen
>
>
>
> Thomas Toka
>
>
>
> - Second Level Support -
>
>
>
> [image: logo_mail]
>
> IP-Projects GmbH & Co. KG
> Am Vogelherd 14
> D - 97295 Waldbrunn
>
> Telefon: 09306 - 76499-0
> FAX: 09306 - 76499-15
> E-Mail: i...@ip-projects.de
>
> Geschäftsführer: Michael Schinzel
> Registergericht Würzburg: HRA 6798
> Komplementär: IP-Projects Verwaltungs GmbH
>
>
>
>
>
> *Von:* Michael Schinzel
> *Gesendet:* Montag, 28. November 2016 18:20
> *An:* Neil Sikka 
> *Cc:* Xen-devel ; Thomas Toka <
> t...@ip-projects.de>
> *Betreff:* AW: [Xen-devel] Payed Xen Admin
>
>
>
> Hello,
>
>
>
> thank you for your response. There are no quemu prozesses which we can
> identify with the ID of the failed guest.
>
>
>
>
>
> Mit freundlichen Grüßen
>
>
>
> Michael Schinzel
>
> - Geschäftsführer -
>
>
>
> [image: https://www.ip-projects.de/logo_mail.png]
> 
>
> IP-Projects GmbH & Co. KG
> Am Vogelherd 14
> D - 97295 Waldbrunn
>
> Telefon: 09306 - 76499-0
> FAX: 09306 - 76499-15
> E-Mail: i...@ip-projects.de
>
> Geschäftsführer: Michael Schinzel
> Registergericht Würzburg: HRA 6798
> Komplementär: IP-Projects Verwaltungs GmbH
>
>
>
>
>
> *Von:* Neil Sikka [mailto:neilsi...@gmail.com ]
> *Gesendet:* Montag, 28. November 2016 14:30
> *An:* Michael Schinzel 
> *Cc:* Xen-devel 
> *Betreff:* Re: [Xen-devel] Payed Xen Admin
>
>
>
> Usually, I've seen (null) domains are not running but their Qemu DMs are
> running. You could probably remove the (null) from the list by using "kill
> -9" on the qemu pids.
>
>
>
> On Nov 27, 2016 11:55 PM, "Michael Schinzel" 
> wrote:
>
> Good Morning,
>
>
>
> we have some issues with our Xen Hosts. It seems it is a xen bug but we do
> not find the solution.
>
>
>
> NameID   Mem VCPUs  State
> Time(s)
>
> Domain-0 0 16192 4 r-
> 147102.5
>
> (null)   2 1 1 --p--d
> 1273.2
>
> vmanager2268 4  1024 1 -b
> 34798.8
>
> vmanager2340 5  1024 1 -b
> 5983.8
>
> vmanager261912   512 1 -b
> 1067.0
>
> vmanager261813  1024 4 -b
> 1448.7
>
> vmanager255714  1024 1 -b
> 2783.5
>
> vmanager187116   512 1 -b
> 3772.1
>
> vmanager259217   512 1 -b
> 19744.5
>
> vmanager256618  2048 1 -b
> 3068.4
>
> vmanager222819   512 1 -b
> 837.6
>
> vmanager224120   512 1 -b
> 997.0
>
> vmanager224421  2048 1 -b
> 1457.9
>
> vmanager227222  2048 1 -b
> 1924.5
>
> vmanager222623  1024 1 -b
> 1454.0
>
> vmanager224524   512 1 -b
> 692.5
>
> vmanager224925   512 1 -b
> 22857.7
>
> vmanager226526  2048 1 -b
> 1388.1
>
> vmanager227027   512 1 -b
> 1250.6
>
> vmanager227128  2048 3 -b
> 2060.8
>
> vmanager227329  1024 1 -b
> 34089.4
>
> vmanager227430  2048 1 -b
> 8585.1
>
> vmanager228131  2048 2 -b
> 1848.9
>
> vmanager228232   512 1 -b
> 755.1
>
> vmanager228833  1024 1 -b
> 543.6
>
> vmanager229234   512 1 -b
> 3004.9
>
> vmanager204135   512 

[Xen-devel] [qemu-upstream-4.6-testing test] 102694: regressions - FAIL

[osstest service owner]

flight 102694 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102694/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt 13 saverestore-support-check fail REGR. vs. 99723
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 99723
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 99723
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail in 102688 
REGR. vs. 99723

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 102688 pass in 
102694
 test-amd64-amd64-xl-multivcpu 22 leak-check/check  fail pass in 102688
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail pass in 102688

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 99723
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 99723

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 102688 never 
pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuba9175c5bde6796851d3b9d888ee488fd0257d05
baseline version:
 qemuuebfc90b51d09e0a3330a4702bb23223cf088eabd

Last test of basis99723  2016-07-27 18:10:12 Z  124 days
Testing same since   102530  2016-11-22 20:11:13 Z6 days   10 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl

Re: [Xen-devel] [Qemu-devel] [PATCH 3/4] 9pfs: use v9fs_init_qiov_from_pdu instead of v9fs_pack

[Stefano Stabellini]

On Thu, 24 Nov 2016, Greg Kurz wrote:
> On Mon, 21 Nov 2016 13:39:31 -0800
> Stefano Stabellini  wrote:
> 
> > v9fs_xattr_read should not access VirtQueueElement elems directly.
> > Move v9fs_init_qiov_from_pdu up in the file and call
> > v9fs_init_qiov_from_pdu instead of v9fs_pack.
> > 
> 
> instead of ? I see v9fs_init_qiov_from_pdu() gets called before calling 
> v9fs_pack().

Sorry wrong description. I'll fix it.


> Also, I don't see the corresponding call to qemu_iovec_destroy() to free the
> allocated iovec.

Good point! I'll add a call.


> > Signed-off-by: Stefano Stabellini 
> > ---
> >  hw/9pfs/9p.c | 58 
> > +-
> >  1 file changed, 29 insertions(+), 29 deletions(-)
> > 
> > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > index 5a20a13..b6ec042 100644
> > --- a/hw/9pfs/9p.c
> > +++ b/hw/9pfs/9p.c
> > @@ -1633,14 +1633,39 @@ out_nofid:
> >  pdu_complete(pdu, err);
> >  }
> >  
> > +/*
> > + * Create a QEMUIOVector for a sub-region of PDU iovecs
> > + *
> > + * @qiov:   uninitialized QEMUIOVector
> > + * @skip:   number of bytes to skip from beginning of PDU
> > + * @size:   number of bytes to include
> > + * @is_write:   true - write, false - read
> > + *
> > + * The resulting QEMUIOVector has heap-allocated iovecs and must be 
> > cleaned up
> > + * with qemu_iovec_destroy().
> > + */
> > +static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu,
> > +size_t skip, size_t size,
> > +bool is_write)
> > +{
> > +QEMUIOVector elem;
> > +struct iovec *iov;
> > +unsigned int niov;
> > +
> > +pdu->s->transport->init_iov_from_pdu(pdu, , , is_write);
> > +
> > +qemu_iovec_init_external(, iov, niov);
> > +qemu_iovec_init(qiov, niov);
> > +qemu_iovec_concat(qiov, , skip, size);
> > +}
> > +
> >  static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp,
> > uint64_t off, uint32_t max_count)
> >  {
> >  ssize_t err;
> >  size_t offset = 7;
> >  uint64_t read_count;
> > -V9fsVirtioState *v = container_of(s, V9fsVirtioState, state);
> > -VirtQueueElement *elem = v->elems[pdu->idx];
> > +QEMUIOVector qiov_full;
> >  
> >  if (fidp->fs.xattr.len < off) {
> >  read_count = 0;
> > @@ -1656,7 +1681,8 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU 
> > *pdu, V9fsFidState *fidp,
> >  }
> >  offset += err;
> >  
> > -err = v9fs_pack(elem->in_sg, elem->in_num, offset,
> > +v9fs_init_qiov_from_pdu(_full, pdu, 0, read_count, false);
> > +err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset,
> >  ((char *)fidp->fs.xattr.value) + off,
> >  read_count);
> >  if (err < 0) {
> > @@ -1732,32 +1758,6 @@ static int coroutine_fn 
> > v9fs_do_readdir_with_stat(V9fsPDU *pdu,
> >  return count;
> >  }
> >  
> > -/*
> > - * Create a QEMUIOVector for a sub-region of PDU iovecs
> > - *
> > - * @qiov:   uninitialized QEMUIOVector
> > - * @skip:   number of bytes to skip from beginning of PDU
> > - * @size:   number of bytes to include
> > - * @is_write:   true - write, false - read
> > - *
> > - * The resulting QEMUIOVector has heap-allocated iovecs and must be 
> > cleaned up
> > - * with qemu_iovec_destroy().
> > - */
> > -static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu,
> > -size_t skip, size_t size,
> > -bool is_write)
> > -{
> > -QEMUIOVector elem;
> > -struct iovec *iov;
> > -unsigned int niov;
> > -
> > -pdu->s->transport->init_iov_from_pdu(pdu, , , is_write);
> > -
> > -qemu_iovec_init_external(, iov, niov);
> > -qemu_iovec_init(qiov, niov);
> > -qemu_iovec_concat(qiov, , skip, size);
> > -}
> > -
> >  static void coroutine_fn v9fs_read(void *opaque)
> >  {
> >  int32_t fid;
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH 2/4] 9pfs: introduce transport specific callbacks

[Stefano Stabellini]

On Thu, 24 Nov 2016, Greg Kurz wrote:
> On Thu, 24 Nov 2016 15:23:10 +0100
> Greg Kurz  wrote:
> 
> > On Thu, 24 Nov 2016 09:31:52 +0100
> > Greg Kurz  wrote:
> > 
> > > On Mon, 21 Nov 2016 13:39:30 -0800
> > > Stefano Stabellini  wrote:
> > >   
> > > > Don't call virtio functions from 9pfs generic code, use generic function
> > > > callbacks instead.
> > > > 
> > > > Signed-off-by: Stefano Stabellini 
> > > > ---
> > > 
> > > Just a couple of indentation and line over 80 characters nits. I'll fix 
> > > them
> > > before pushing to 9p-next.
> > > 
> > > Reviewed-by: Greg Kurz 
> > >   
> > 
> > Hmm... second thought...
> > 
> 
> [...]
> 
> > > > +
> > > > +static inline int v9fs_register_transport(V9fsState *s, struct 
> > > > V9fsTransport *t)
> > > > +{
> > > > +if (s->transport) {
> > > > +return -EINVAL;
> > > > +}
> 
> Calling v9fs_register_transport() several times for the same V9fsState looks
> more like a bug than an error...

Yes, you are right. I can turn this into an assert.


> also, is it possible to have several 9pfs
> shares with different transports ?

I think, at least theoretically, is possible. For example Xen HVM
guests, the ones most similar to KVM guests, already support virtio as a
transport. Additionally they will be able to support the Xen based
transport too. (Xen PV guests will only support
the Xen based transport as they don't support virtio in general.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH 2/4] 9pfs: introduce transport specific callbacks

[Stefano Stabellini]

On Thu, 24 Nov 2016, Greg Kurz wrote:
> > > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> > > index 1782e4a..e1a37a4 100644
> > > --- a/hw/9pfs/virtio-9p-device.c
> > > +++ b/hw/9pfs/virtio-9p-device.c
> > > @@ -20,7 +20,9 @@
> > >  #include "hw/virtio/virtio-access.h"
> > >  #include "qemu/iov.h"
> > >  
> > > -void virtio_9p_push_and_notify(V9fsPDU *pdu)
> > > +static struct V9fsTransport virtio_9p_transport;
> 
> ... shouldn't this be const ?

Yes, makes sense.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

[Julien Grall]

On 28/11/16 18:09, Volodymyr Babchuk wrote:

Hello,


Hello Volodymyr,


On 28 November 2016 at 18:14, Julien Grall  wrote:

On 24/11/16 21:10, Volodymyr Babchuk wrote:

My name is Volodymyr Babchuk, I'm working on EPAM Systems with bunch
of other guys like Artem Mygaiev or Andrii Anisov. My responsibility
there is security in embedded systems.

I would like to discuss approaches to OP-TEE support in XEN.



Thank you for sharing this, I am CC-ing some people who showed interest on
accessing trusted firmware from the guest.

In the future, please try to CC relevant people (in this case ARM
maintainers) to avoid any delay on the answer.

Thanks. I never worked with XEN community earlier, so I don't know who is who :)


You can give a look to the MAINTAINERS file at the root xen.git.

[...]


You can find patches at [1] if you are interested.
During working on this PoC I have identified main questions that
should be answered:

On XEN side:
1. SMC handling in XEN. There are many different SMCs and only portion
of them belong to TEE. We need some SMC dispatcher that will route
calls to different subsystems. Like PSCI calls to PSCI subsystem, TEE
calls to TEE subsystem.



So from my understanding of this paragraph, all SMC TEE calls should have a
guest ID in the command. We don't expect command affecting all TEE. Correct?

Yes. Idea is to trap SMC, alter it, add guest ID (into r7, as SMCCC
says) and then
do real SMC to pass it to TEE.

But I'm not get this: "We don't expect command affecting all TEE".
What did you mean?


I mean, is there any command that will affect the trusted OS (e.g reset 
it, or else) in whole and not only the session for a given guest?








2. Support for different TEEs. There are OP-TEE, Google Trusty, TI
M-Shield... They all work thru SMC, but have different protocols.
Currently, we are aimed only to OP-TEE. But we need some generic API
in XEN, so support for new TEE can be easily added.


For instance you

Hm?

Is there any  generic way to detect which TEE is been in used and the
version?

Yes, according to SMCCC, there call number 0xBF00FF01 that should
return Trusted OS UID.
OP-TEE supports this call. I hope, other TEEs also support it. In this
way we can which TrustedOS is running on host.


Looking at the SMCC, this SMC call seems to be mandatory.





3. TEE services. Hypervisor should inform TEE when new guest is
created or destroyed, it should tag SMCs to TEE with GuestID, so TEE
can isolate guest data on its side.

4. SMC mangling. RichOS communicates with TEE using shared buffers, by
providing physical memory addresses. Hypervisor should convert IPAs to
PAs.



I am actually concerned about this bit. From my understanding, the
hypervisor would need some knowledge of the SMC.

Yes, it was my first idea - separate subsystem in the hypervisor that
handles SMC calls for different TEEs. This subsystems has a number of
backends. One for each TEE.


So are the OP-TEE SMC calls fully standardized? By that I mean they will not
change across version?

No, they are not standardized and they can change in the future.
OP-TEE tries to be backward-compatible, though. So hypervisor can drop
unknown capability flags in SMC call GET_CAPABILITIES. In this way it
can ensure that guest will use only  APIs that are known by
hypervisor.


How about other TEE?

I can't say for sure. But I think, situation is the same as with OP-TEE


By any chance, is there a TEE specification out somewhere?




If not, then it might be worth to consider a 3rd solution where the TEE SMC
calls are forwarded to a specific domain handling the SMC on behalf of the
guests. This would allow to upgrade the TEE layer without having to upgrade
the hypervisor.

Yes, this is good idea. How this can look? I imagine following flow:
Hypervisor traps SMC, uses event channel to pass request to Dom0. Some
userspace daemon receives it, maps pages with request data, alters is
(e.g. by replacing IPAs with PAs), sends request to hypervisor to
issue real SMC, then alters response and only then returns data back
to guest.


The event channel is only a way to notify (similar to an interrupt), you 
would need a shared memory page between the hypervisor and the client to 
communicate the SMC information.


I was thinking to get advantage of the VM event API for trapping the 
SMC. But I am not sure if it is the best solution here. Stefano, do you 
have any opinions here?




Is this even possible with current APIs available to dom0?


It is always possible to extend the API if something is missing :).



I can see only one benefit there - this code will be not in
hypervisor. And there are number of drawbacks:

Stability: if this userspace demon will crash or get killed by, say,
OOM, we will lose information about all opened sessions, mapped shared
buffers, etc.That would be complete disaster.


I disagree on your statement, you would gain in isolation. If your 
userspace crashes (because of an emulation bug), you 

[Xen-devel] [ovmf test] 102696: all pass - PUSHED

[osstest service owner]

flight 102696 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102696/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf bb767506b265b1cdbf0dbec58c9a3f4c6be6ab2b
baseline version:
 ovmf 4e3b05a49f454bc257252ae9090421e3c8447737

Last test of basis   102691  2016-11-28 07:45:08 Z0 days
Testing same since   102696  2016-11-28 13:13:57 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=bb767506b265b1cdbf0dbec58c9a3f4c6be6ab2b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ 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 ovmf 
bb767506b265b1cdbf0dbec58c9a3f4c6be6ab2b
+ branch=ovmf
+ revision=bb767506b265b1cdbf0dbec58c9a3f4c6be6ab2b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ 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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xbb767506b265b1cdbf0dbec58c9a3f4c6be6ab2b = x ']'
+ : 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/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

[Xen-devel] [PULL 1/4] xen_disk: split discard input to match internal representation

[Stefano Stabellini]

From: Olaf Hering 

The guest sends discard requests as u64 sector/count pairs, but the
block layer operates internally with s64/s32 pairs. The conversion
leads to IO errors in the guest, the discard request is not processed.

  domU.cfg:
  'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
  domU:
  mkfs.ext4 -F /dev/xvda
  Discarding device blocks: failed - Input/output error

Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
Add input range checking to avoid overflow.

Fixes f313520 ("xen_disk: add discard support")

Signed-off-by: Olaf Hering 
Reviewed-by: Eric Blake 
Reviewed-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 42 --
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 3a7dc19..456a2d5 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -660,6 +660,38 @@ static void qemu_aio_complete(void *opaque, int ret)
 qemu_bh_schedule(ioreq->blkdev->bh);
 }
 
+static bool blk_split_discard(struct ioreq *ioreq, blkif_sector_t 
sector_number,
+  uint64_t nr_sectors)
+{
+struct XenBlkDev *blkdev = ioreq->blkdev;
+int64_t byte_offset;
+int byte_chunk;
+uint64_t byte_remaining, limit;
+uint64_t sec_start = sector_number;
+uint64_t sec_count = nr_sectors;
+
+/* Wrap around, or overflowing byte limit? */
+if (sec_start + sec_count < sec_count ||
+sec_start + sec_count > INT64_MAX >> BDRV_SECTOR_BITS) {
+return false;
+}
+
+limit = BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS;
+byte_offset = sec_start << BDRV_SECTOR_BITS;
+byte_remaining = sec_count << BDRV_SECTOR_BITS;
+
+do {
+byte_chunk = byte_remaining > limit ? limit : byte_remaining;
+ioreq->aio_inflight++;
+blk_aio_pdiscard(blkdev->blk, byte_offset, byte_chunk,
+ qemu_aio_complete, ioreq);
+byte_remaining -= byte_chunk;
+byte_offset += byte_chunk;
+} while (byte_remaining > 0);
+
+return true;
+}
+
 static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 {
 struct XenBlkDev *blkdev = ioreq->blkdev;
@@ -708,12 +740,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq)
 break;
 case BLKIF_OP_DISCARD:
 {
-struct blkif_request_discard *discard_req = (void *)>req;
-ioreq->aio_inflight++;
-blk_aio_pdiscard(blkdev->blk,
- discard_req->sector_number << BDRV_SECTOR_BITS,
- discard_req->nr_sectors << BDRV_SECTOR_BITS,
- qemu_aio_complete, ioreq);
+struct blkif_request_discard *req = (void *)>req;
+if (!blk_split_discard(ioreq, req->sector_number, req->nr_sectors)) {
+goto err;
+}
 break;
 }
 default:
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PULL for-2.8 0/4] tags/xen-20161128-tag

[Stefano Stabellini]

The following changes since commit 00227fefd2059464cd2f59aed29944874c630e2f:

  Update version for v2.8.0-rc1 release (2016-11-22 22:29:08 +)

are available in the git repository at:

  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161128-tag

for you to fetch changes up to e514379de52573131ccc47441787e5fab6dbfc08:

  xen: ignore direction in bufioreq handling (2016-11-28 11:26:29 -0800)


Xen 2016/11/28


Jan Beulich (3):
  xen: fix quad word bufioreq handling
  xen: slightly simplify bufioreq handling
  xen: ignore direction in bufioreq handling

Olaf Hering (1):
  xen_disk: split discard input to match internal representation

 hw/block/xen_disk.c | 42 --
 xen-hvm.c   | 22 --
 2 files changed, 52 insertions(+), 12 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PULL 3/4] xen: slightly simplify bufioreq handling

[Stefano Stabellini]

From: Jan Beulich 

There's no point setting fields always receiving the same value on each
iteration, as handle_ioreq() doesn't alter them anyway. Set state and
count once ahead of the loop, drop the redundant clearing of
data_is_ptr, and avoid the meaningless (because count is 1) setting of
df altogether.

Also avoid doing an unsigned long calculation of size when the field to
be initialized is only 32 bits wide (and the shift value in the range
0...3).

Signed-off-by: Jan Beulich 
Reviewed-by: Paul Durrant 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 xen-hvm.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen-hvm.c b/xen-hvm.c
index d74e233..124ae10 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOState *state)
 }
 
 memset(, 0x00, sizeof(req));
+req.state = STATE_IOREQ_READY;
+req.count = 1;
 
 for (;;) {
 uint32_t rdptr = buf_page->read_pointer, wrptr;
@@ -1009,15 +1011,11 @@ static int handle_buffered_iopage(XenIOState *state)
 break;
 }
 buf_req = _page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
-req.size = 1UL << buf_req->size;
-req.count = 1;
+req.size = 1U << buf_req->size;
 req.addr = buf_req->addr;
 req.data = buf_req->data;
-req.state = STATE_IOREQ_READY;
 req.dir = buf_req->dir;
-req.df = 1;
 req.type = buf_req->type;
-req.data_is_ptr = 0;
 xen_rmb();
 qw = (req.size == 8);
 if (qw) {
@@ -1032,6 +1030,13 @@ static int handle_buffered_iopage(XenIOState *state)
 
 handle_ioreq(state, );
 
+/* Only req.data may get updated by handle_ioreq(), albeit even that
+ * should not happen as such data would never make it to the guest.
+ */
+assert(req.state == STATE_IOREQ_READY);
+assert(req.count == 1);
+assert(!req.data_is_ptr);
+
 atomic_add(_page->read_pointer, qw + 1);
 }
 
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PULL 2/4] xen: fix quad word bufioreq handling

[Stefano Stabellini]

From: Jan Beulich 

We should not consume the second slot if it didn't get written yet.
Normal writers - i.e. Xen - would not update write_pointer between the
two writes, but the page may get fiddled with by the guest itself, and
we're better off avoiding to enter an infinite loop in that case.

Reported-by: yanghongke 
Signed-off-by: Jan Beulich 
Reviewed-by: Paul Durrant 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 xen-hvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen-hvm.c b/xen-hvm.c
index 99b8ee8..d74e233 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOState *state)
 xen_rmb();
 qw = (req.size == 8);
 if (qw) {
+if (rdptr + 1 == wrptr) {
+hw_error("Incomplete quad word buffered ioreq");
+}
 buf_req = _page->buf_ioreq[(rdptr + 1) %
IOREQ_BUFFER_SLOT_NUM];
 req.data |= ((uint64_t)buf_req->data) << 32;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PULL 4/4] xen: ignore direction in bufioreq handling

[Stefano Stabellini]

From: Jan Beulich 

There's no way to communicate back read data, so only writes can ever
be usefully specified. Ignore the field, paving the road for eventually
re-using the bit for something else in a few (many?) years time.

Signed-off-by: Jan Beulich 
Reviewed-by: Paul Durrant 
Acked-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
---
 xen-hvm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen-hvm.c b/xen-hvm.c
index 124ae10..0892361 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -997,6 +997,7 @@ static int handle_buffered_iopage(XenIOState *state)
 memset(, 0x00, sizeof(req));
 req.state = STATE_IOREQ_READY;
 req.count = 1;
+req.dir = IOREQ_WRITE;
 
 for (;;) {
 uint32_t rdptr = buf_page->read_pointer, wrptr;
@@ -1014,7 +1015,6 @@ static int handle_buffered_iopage(XenIOState *state)
 req.size = 1U << buf_req->size;
 req.addr = buf_req->addr;
 req.data = buf_req->data;
-req.dir = buf_req->dir;
 req.type = buf_req->type;
 xen_rmb();
 qw = (req.size == 8);
@@ -1031,10 +1031,12 @@ static int handle_buffered_iopage(XenIOState *state)
 handle_ioreq(state, );
 
 /* Only req.data may get updated by handle_ioreq(), albeit even that
- * should not happen as such data would never make it to the guest.
+ * should not happen as such data would never make it to the guest (we
+ * can only usefully see writes here after all).
  */
 assert(req.state == STATE_IOREQ_READY);
 assert(req.count == 1);
+assert(req.dir == IOREQ_WRITE);
 assert(!req.data_is_ptr);
 
 atomic_add(_page->read_pointer, qw + 1);
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/3] xen: slightly simplify bufioreq handling

[Stefano Stabellini]

On Fri, 25 Nov 2016, Jan Beulich wrote:
> There's no point setting fields always receiving the same value on each
> iteration, as handle_ioreq() doesn't alter them anyway. Set state and
> count once ahead of the loop, drop the redundant clearing of
> data_is_ptr, and avoid the meaningless setting of df altogether.
> 
> Also avoid doing an unsigned long calculation of size when the field to
> be initialized is only 32 bits wide (and the shift value in the range
> 0...3).
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Paul Durrant 

Reviewed-by: Stefano Stabellini 


> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOS
>  }
>  
>  memset(, 0x00, sizeof(req));
> +req.state = STATE_IOREQ_READY;
> +req.count = 1;
>  
>  for (;;) {
>  uint32_t rdptr = buf_page->read_pointer, wrptr;
> @@ -1009,15 +1011,11 @@ static int handle_buffered_iopage(XenIOS
>  break;
>  }
>  buf_req = _page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
> -req.size = 1UL << buf_req->size;
> -req.count = 1;
> +req.size = 1U << buf_req->size;
>  req.addr = buf_req->addr;
>  req.data = buf_req->data;
> -req.state = STATE_IOREQ_READY;
>  req.dir = buf_req->dir;
> -req.df = 1;
>  req.type = buf_req->type;
> -req.data_is_ptr = 0;
>  xen_rmb();
>  qw = (req.size == 8);
>  if (qw) {
> @@ -1032,6 +1030,13 @@ static int handle_buffered_iopage(XenIOS
>  
>  handle_ioreq(state, );
>  
> +/* Only req.data may get updated by handle_ioreq(), albeit even that
> + * should not happen as such data would never make it to the guest.
> + */
> +assert(req.state == STATE_IOREQ_READY);
> +assert(req.count == 1);
> +assert(!req.data_is_ptr);
> +
>  atomic_add(_page->read_pointer, qw + 1);
>  }
>  
> 
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/3] xen: fix quad word bufioreq handling

[Stefano Stabellini]

On Fri, 25 Nov 2016, Jan Beulich wrote:
> We should not consume the second slot if it didn't get written yet.
> Normal writers - i.e. Xen - would not update write_pointer between the
> two writes, but the page may get fiddled with by the guest itself, and
> we're better off avoiding to enter an infinite loop in that case.
> 
> Reported-by: yanghongke 
> Signed-off-by: Jan Beulich 

Reviewed-by: Stefano Stabellini 


> v2: Bail (using hw_error()) instead of just breaking the loop.
> 
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOS
>  xen_rmb();
>  qw = (req.size == 8);
>  if (qw) {
> +if (rdptr + 1 == wrptr) {
> +hw_error("Incomplete quad word buffered ioreq");
> +}
>  buf_req = _page->buf_ioreq[(rdptr + 1) %
> IOREQ_BUFFER_SLOT_NUM];
>  req.data |= ((uint64_t)buf_req->data) << 32;
> 
> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] arm64: Approach for DT based NUMA and issues

[Julien Grall]

On 26/11/16 06:59, Vijay Kilari wrote:

Hi,


Hi Vijay,

This mail is mixing two distinct problems:
1) Making Xen NUMA-aware
2) Make DOM0 NUMA-aware

As mentioned in another part of this thread, those problems should be 
one by one rather than together.


I will focus on problem 1) while answering this e-mail.


   Below basic write up on DT based NUMA feature support for arm64 platform.
I have attempted to get NUMA support, However I face below issues. I would like
to discuss these issues. Please let me know your comments on this. Yet to look
at ACPI support.

DT based NUMA support for arm64 platform

For Xen boot on NUMA arm64 platform, Xen needs to parse
CPU and Memory nodes for DT based booting mechanism. Here I would
like to discuss about DT based booting mechanism and the issues
related to it.

1) Parsing CPU and Memory nodes:
---

The numa information associated for CPU and Memory are passed in DT
using numa-node-id u32-interger value. More information about NUMA binding
is available in linux kernel @ Documentation/devicetree/bindings/numa.txt

Similar to Linux kernel, cpu and memory nodes of DT are parsed
and numa-node-id information is populated in cpu_parsed and memory_parsed
node_t mask.

When booting in UEFI mode, UEFI passes memory information to Dom0
using EFI memory descriptor table and deletes the memory nodes
from the host DT. However to fetch the memory numa node id, memory DT
node should not be deleted by EFI stub.

ISSUE: When memory node is _NOT_ deleted by EFI stub from host DT,
Xen identifies the memory node [xen/arch/arm/bootfdt.c, early_scan_node() ]
which adds memory ranges to bootinfo.mem structure there by adding duplicate
entry and eventually initialization fails.

Possible Solution: While adding new memory region to bootinfo.mem, check for
duplicate entries and back off if entry is already available from UEFI mem info
table.


I think we should have a different approach. I actually like the 
approach suggested by Andre in [1]), which is if the UEFI memory mapped 
exists (i.e bootinfo.mem is already filled), then DT is only used to get 
NUMA node information.




2) Parsing CPU nodes:
-
The CPU nodes are parsed to extract numa-node-id info for each cpu and
cpu_nodemask is populated.

The MPIDR register value is read for each CPU and cpu_to_node[] is populated.


To emphase here, cpu_to_node will be indexed using Xen CPUID and not 
MPIDR. They can be different and Xen does not have a clue of the MPIDR 
except in very few places.




3) Parsing Memory nodes:
--
For all the DT memory nodes in the flattend DT, start address, size
and numa-node-id value is extracted and stored in "node_memblk_range[]"
which is of type struct node.

Each bootinfo.mem entry from UEFI is verified against node_memblk_range[] and
NODE_DATA is populated with start PFN, end PFN and nodeid.

Populating memnodemap:

The memnodemap[] is allocated from heap and using the NODE_DATA structure,
the memnodemap[] is populated with nodeid for each page index.

This memnodemap info is used to fetch memory node id for a given page
by calling phys_to_nid() by memory allocator.

ISSUE: phys_to_nid() is called by memory allocator before memnodemap[]
is initialized.

Since memnodemap[] is allocated from heap, and hence boot allocator should
be initialized. The boot_allocator() needs phys_to_nid() which is not
available untill memnodemap[] is initialized. So there is deadlock situation
during initialization. To overcome this phsy_to_nid() should rely on
node_memblk_range[] to get nodeid untill memnodemap[] is initialized.


Looking at the code, boot_allocator() does not need phys_to_nid until 
the end. So it would be perfectly fine to use alloc_boot_pages to 
allocate memnodemap.




4) Generating memory nodes for DOM0
-
Linux kernel device drivers that uses devm_zalloc(), tries to allocate memory
from local memory node. So Dom0 needs to have memory allocated on all the
available nodes of the system.

Ex: SMMU driver of device on node 1 tries to allocate memory
on node 1.

ISSUE:
 - Dom0's memory should be split across all the available memory nodes
   of the system and memory nodes should be generated accordingly.
 - Memory DT node generated by Xen for Dom0 should populate numa-node-id
   information.


If you drop numa-node-id property from every node, DOM0 will not try to 
use NUMA. Is there any specific reason to not do that?


Those properties could be re-introduced later on when vNUMA will be 
brought up.


Regards,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg02499.html


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 1/2] xen_platform: unplug also SCSI disks

[Stefano Stabellini]

On Thu, 24 Nov 2016, Olaf Hering wrote:
> On Fri, Oct 21, Olaf Hering wrote:
> 
> > Using 'vdev=sd[a-o]' will create an emulated LSI controller, which can
> > be used by the emulated BIOS to boot from disk. If the HVM domU has also
> > PV driver the disk may appear twice in the guest. To avoid this an
> > unplug of the emulated hardware is needed, similar to what is done for
> > IDE and NIC drivers already.
> 
> How are these patches supposed to find their way into
> qemu-xen.git#staging? Do I have to wait until #staging gets updated to
> qemu-2.8+ at some point, or would you please cherry-pick these two commits:
> 
> 3513201 xen_platform: SUSE xenlinux unplug for emulated PCI
> 78f6689 xen_platform: unplug also SCSI disks

Anthony, are you going to take care of this?
However, given the state of the release, they'll need a release-ack to
be applied.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] some thoughts about merlot{0|1} issues [was: Re: [xen-unstable test] 102522: tolerable FAIL - PUSHED]

[Boris Ostrovsky]

On 11/28/2016 12:19 PM, Dario Faggioli wrote:
> On Mon, 2016-11-28 at 08:48 -0500, Boris Ostrovsky wrote:
>> On 11/24/2016 10:31 AM, Jan Beulich wrote:
>>>  
>>> This indeed looks surprising for a half way modern system - is the
>>> BIOS perhaps limiting C-states (maybe instructed to via BIOS
>>> setup)?
>> IIRC some BIOSes indeed provided an option to disable C2. Dumping
>> SSDT
>> would tell us whether C2 is there is BIOS is not accessible.
>>
> I will try to extract that.
>
> In any case, what I'm wondering is, could this ACPI / PM thing be
> linked to the behavior we are seeing?

I find it somewhat unlikely.

BTW, I wouldn't worry about C2 specifically --- it's pretty clear that
no C-state stats are collected at all:

Nov 28 08:07:42.146057 (XEN) active state:  C-1
Nov 28 08:07:42.153968 (XEN) max_cstate:C7
Nov 28 08:07:42.153998 (XEN) states:
Nov 28 08:07:42.154021 (XEN) C1:type[C1] latency[000] usage[] 
method[ HALT] duration[0]
Nov 28 08:07:42.161992 (XEN) C0:usage[] duration[3907882618433]


duration is the only reported value and most likely it's a NOW(). And
the reason C1 is still mentioned is because it is a required C-state,
whether or not it's in SSDT.

It is strange but I don't see anything in the serial log that would
indicate a problem.


>
> I'm not sure I see how... perhaps the system gets too hot and its
> throttled down? (Yes, shooting in the dark, I know.)

I'd expect an event to be triggered (SMI?) and a warning of some sort to
be printed.

-boris



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] MAINTAINERS: Update xen-devel mailing list address

[Stefano Stabellini]

On Fri, 25 Nov 2016, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD 

Acked-by: Stefano Stabellini 


>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4a60579..1379317 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -309,7 +309,7 @@ Guest CPU Cores (Xen):
>  X86
>  M: Stefano Stabellini 
>  M: Anthony Perard 
> -L: xen-de...@lists.xensource.com
> +L: xen-de...@lists.xenproject.org
>  S: Supported
>  F: xen-*
>  F: */xen*
> -- 
> Anthony PERARD
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

[Volodymyr Babchuk]

Hello,

On 28 November 2016 at 18:14, Julien Grall  wrote:
> On 24/11/16 21:10, Volodymyr Babchuk wrote:
>>
>> Hello all,
>
>
> Hello,
>
>> My name is Volodymyr Babchuk, I'm working on EPAM Systems with bunch
>> of other guys like Artem Mygaiev or Andrii Anisov. My responsibility
>> there is security in embedded systems.
>>
>> I would like to discuss approaches to OP-TEE support in XEN.
>
>
> Thank you for sharing this, I am CC-ing some people who showed interest on
> accessing trusted firmware from the guest.
>
> In the future, please try to CC relevant people (in this case ARM
> maintainers) to avoid any delay on the answer.
Thanks. I never worked with XEN community earlier, so I don't know who is who :)

>
>
>> But first small introduction for those who is not familiar with topic:
>>
>> There are such thing as Security Extensions for ARM cores. It is part
>> of bigger thing - ARM TrustZone. Security extensions allows CPU to
>> work in two states: Normal (Non-Secure) and Secure.
>> Other parts of TrustZone provide hardware protection for peripherals,
>> memory regions, etc. So, when CPU is running in secure state, it have
>> access to all peripherals and memories, also it can forbid access to
>> some of those resources from Normal state. Secure state have own
>> Supervisor and User modes, so we can run OS there.
>> Just to be clear, CPU can run in following modes; user, supervisor,
>> hypervisor, secure monitor, secure user and secure supervisor. Last
>> two basically are the same as normal USR and SVC, but in secure state.
>> And Secure Monitor is special mode, that can switch Secure state to
>> Non-secure state and back. SMC instruction takes into this mode.
>> So, we can run one OS in secure state and one in non-secure state.
>> They will be mostly independent from each other. In normal
>> (non-secure) mode we run, say, Linux. And in Secure mode we run some
>> Trusted OS (or Secure Os). Secure OS provides services like
>> cryptography, secure storage, DRM, virtual SIM, etc. to Normal world
>> OS (it also called "Rich OS". It can be Linux for example.).
>> There are standard created by GlobalPlatform that is called "Trusted
>> Execution Environment" (TEE). It defines requirements and APIs for the
>> Secure OS. There are number number of Secure OSes that tries to be
>> conform with TEE specification and OP-TEE is one of them.
>>
>> CPU is normally running in Non-Secure state. When normal world OS
>> needs some services from Secure OS, it issues SMC instruction with
>> command data. This instruction puts processor into Secure Monitor
>> Mode, where secure monitor code examines request. If it is request to
>> Secure OS, it switches processor to Secure Supervisor mode and passes
>> request to Secure OS. When Secure OS finishes work, it also issues SMC
>> instruction and Secure Monitor switches processor back to non-secure
>> state, returning control to Rich OS.
>> SMC instruction can be used not only to communicate with SecureOS, but
>> also for other services like power control, control of processor
>> cores, etc. ARM wrote document "SMC Calling Convention" which in
>> detail describes how this instruction can be used.  By the way, SMCCC
>> requires to pass Virtual Machine ID in one of the registers during SMC
>> call.
>>
>> Now let's get back to XEN. We want XEN to provide TEE services to Dom0
>> and guests. I can see different approaches to this:
>>
>>  - One of them I call "Emulated TEE". Guests does not have access to
>> real TEE OS. Instead somewhere (in Dom0) we run instance of TEE for
>> each of the Guests. This provides perfect isolation, as TEE instances
>> does not anything about each one. But we will miss all hardware
>> benefits like cryptographic acceleration.
>>  - Another way is to allow guests to work with real TEE running Secure
>> state. In this case TEE should be aware about guests to track shared
>> memories, opened sessions, etc. It requires some careful programming
>> to ensure that guest belongings are isolated from each other. But as
>> reward we are much closer to original TrustZone desing.
>>
>> Personally I prefer second approach. I, even, did small PoC that
>> allows different guests to work with OP-TEE (but not simultaneously!).
>
>
> I agree that the first approach is not good because you can't get advantage
> of the hardware. However, I have some concerns about the second (see below).
>
> Bear in mind that I don't know much about TEE :).
>
>> You can find patches at [1] if you are interested.
>> During working on this PoC I have identified main questions that
>> should be answered:
>>
>> On XEN side:
>> 1. SMC handling in XEN. There are many different SMCs and only portion
>> of them belong to TEE. We need some SMC dispatcher that will route
>> calls to different subsystems. Like PSCI calls to PSCI subsystem, TEE
>> calls to TEE subsystem.
>
>
> So from my understanding of this paragraph, all SMC TEE calls should have a
> guest ID in the command. We 

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v2 01/11] multiboot2: Rename Multiboot to Multiboot2

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Multiboot2 is proper name of the boot protocol. Multiboot is name of older 
> boot
> protocol. So, rename Multiboot to Multiboot2 to not confuse the reader.
> 
> Signed-off-by: Daniel Kiper 
> ---
>  doc/multiboot.texi |  112 
> ++--

What about file name itself? It makes it impossible for multiboot and
multiboot2 documentation to coexist (or forces every downstream to
rename it anyway).


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v2 06/11] multiboot2: Add description of EFI image handle tags

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Signed-off-by: Daniel Kiper 
> ---
>  doc/multiboot.texi |   28 
>  doc/multiboot2.h   |   16 
>  2 files changed, 44 insertions(+)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index cc1edab..dca3e62 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -1288,6 +1288,34 @@ u32 | size = 8  |
>  
>  This tag indicates ExitBootServices wasn't called
>  
> +@subsection EFI 32-bit image handle pointer
> +@example
> +@group
> ++---+
> +u32 | type = 19 |
> +u32 | size = 12 |
> +u32 | pointer   |

Why it is not u_phys or u_virt as appropriate?

> ++---+
> +@end group
> +@end example
> +
> +This tag contains pointer to EFI i386 image handle.
> +Usually it is boot loader image handle.
> +
> +@subsection EFI 64-bit image handle pointer
> +@example
> +@group
> ++---+
> +u32 | type = 20 |
> +u32 | size = 16 |
> +u64 | pointer   |

Same. Again, why there are two tags in the first place? It sounds like
perfect fit for "data of the same size as target architecture
[virtual|physical] address size".



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.5-testing test] 102692: regressions - FAIL

[osstest service owner]

flight 102692 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102692/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt 13 saverestore-support-check fail REGR. vs. 99725

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 14 guest-saverestore.2 fail in 102680 pass in 
102684
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
102680 pass in 102692
 test-amd64-i386-freebsd10-amd64 10 guest-start   fail in 102684 pass in 102692
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 102684 pass 
in 102692
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 102684 
pass in 102692
 test-amd64-i386-libvirt  14 guest-saverestore  fail pass in 102680
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
102680
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore  fail pass in 102684
 test-armhf-armhf-libvirt-raw  9 debian-di-install  fail pass in 102684
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 
102684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 99725
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail in 102680 like 99725
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 102684 blocked 
in 99725
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 102684 
like 99725
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 99725
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 99725

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 10 guest-start  fail in 102684 never pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 102684 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 102684 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass

version targeted for testing:
 qemuu37a460ca696381bb14dfbf012d7a062c7c05c324
baseline version:
 qemuu835c204f1196ab8f5213a9dc5299ed76e748cdca

Last test of basis99725  2016-07-27 18:10:31 Z  123 days
Testing same since   102533  2016-11-22 20:11:10 Z5 days   10 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services

[Andrei Borzenkov]

24.11.2016 23:40, Daniel Kiper пишет:
> Signed-off-by: Daniel Kiper 
> ---
> v2 - suggestions/fixes:
>- clarify physical address meaning for EFI amd64
>  mode with boot services enabled
>  (suggested by Andrew Cooper).
> ---
>  doc/multiboot.texi |  115 
> +++-
>  doc/multiboot2.h   |2 +
>  2 files changed, 115 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> index f0f167e..cc1edab 100644
> --- a/doc/multiboot.texi
> +++ b/doc/multiboot.texi
> @@ -534,6 +534,66 @@ The physical address to which the boot loader should 
> jump in order to
>  start running the operating system.
>  @end table
>  
> +@subsection EFI i386 entry address tag of Multiboot2 header
> +
> +@example
> +@group
> ++---+
> +u16 | type = 8  |
> +u16 | flags |
> +u32 | size  |
> +u_virt  | entry_addr|
> ++---+
> +@end group
> +@end example
> +
> +All of the address fields in this tag are physical addresses.

Should not entry_addr be u_phys then? Otherwise what is exact difference
between u_phys and u_virt? Also for type == 3?

> +The meaning of each is as follows:
> +
> +@table @code
> +
> +@item entry_addr
> +The physical address to which the boot loader should jump in order to
> +start running EFI i386 compatible operating system code.
> +@end table
> +
> +This tag is taken into account only on EFI i386 platforms
> +when Multiboot2 image header contains EFI boot services tag.
> +Then entry point specified in ELF header and the entry address
> +tag of Multiboot2 header are ignored.
> +
> +@subsection EFI amd64 entry address tag of Multiboot2 header
> +
> +@example
> +@group
> ++---+
> +u16 | type = 9  |
> +u16 | flags |
> +u32 | size  |
> +u_virt  | entry_addr|
> ++---+
> +@end group
> +@end example
> +
> +All of the address fields in this tag are physical addresses (paging
> +mode is enabled and any memory space defined by the UEFI memory map
> +is identity mapped, hence, virtual address equals physical address;

Same here; it is confusing marking field as u_virt and describing it
immediately as "physical address".

> +Unified Extensible Firmware Interface Specification, Version 2.6,
> +section 2.3.4, x64 Platforms, boot services). The meaning of each
> +is as follows:
> +
> +@table @code
> +
> +@item entry_addr
> +The physical address to which the boot loader should jump in order to
> +start running EFI amd64 compatible operating system code.
> +@end table
> +
> +This tag is taken into account only on EFI amd64 platforms
> +when Multiboot2 image header contains EFI boot services tag.
> +Then entry point specified in ELF header and the entry address
> +tag of Multiboot2 header are ignored.
> +

Why do we have two different tags for what is effectively the same
purpose? Is it possible for the same image to have both of them? Just
for my understanding.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] arm64: Approach for DT based NUMA and issues

[Julien Grall]

Hi Dario,

On 28/11/16 12:30, Dario Faggioli wrote:

On Mon, 2016-11-28 at 16:32 +0530, Vijay Kilari wrote:

On Mon, Nov 28, 2016 at 2:21 AM, Dario Faggioli
 wrote:


That makes perfect sense to me, and FWIW, is also what I'd do. In
fact,
the whole point of what I was saying was not to confuse Xen NUMA
support and Dom0 NUMA support; if we want to do both of them, the
latter right after the former, fine, but they're separate things
indeed.

  Yes, agreed. Whatever the existing Xen NUMA-Aware code is
completely kept
under x86, which can be used for arm as well. So needs cleanup and
make common
for both archs.


Sure.


  Regarding Dom0 NUMA-aware, in arm Dom0 is completely not NUMA-
aware, not even
to the extent supported in x86.


Well, Dom0 is ~0% NUMA aware on x86. But it's not important whose Dom0
is _less_ NUMA aware. What I (and also Julien, AFAICT) am talking about
is that we should start make Xen NUMA aware for ARM, before looking at
Dom0.


I totally agree with this sentence. Let's focus on making Xen NUMA-aware 
first.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3.1 10/15] xen/x86: split Dom0 build into PV and PVHv2

[Roger Pau Monne]

On Thu, Nov 17, 2016 at 03:49:22AM -0700, Jan Beulich wrote:
> >>> On 16.11.16 at 19:02,  wrote:
> > On Fri, Nov 11, 2016 at 09:53:49AM -0700, Jan Beulich wrote:
> >> >>> On 29.10.16 at 10:59,  wrote:
> >> > --- a/xen/arch/x86/setup.c
> >> > +++ b/xen/arch/x86/setup.c
> >> > @@ -67,6 +67,16 @@ unsigned long __read_mostly cr4_pv32_mask;
> >> >  static bool_t __initdata opt_dom0pvh;
> >> >  boolean_param("dom0pvh", opt_dom0pvh);
> >> >  
> >> > +/*
> >> > + * List of parameters that affect Dom0 creation:
> >> > + *
> >> > + *  - hvm   Create a PVHv2 Dom0.
> >> > + *  - shadowUse shadow paging for Dom0.
> >> > + */
> >> > +static void parse_dom0_param(char *s);
> >> 
> >> Please try to avoid such forward declarations.

OK, so would you prefer to place the custom_param call after the function 
definition? I've done it that way (with the forward declaration) because it's 
the way other options are already implemented.
 
> >> > @@ -1543,6 +1574,14 @@ void __init noreturn __start_xen(unsigned long 
> >> > mbi_p)
> >> >  if ( opt_dom0pvh )
> >> >  domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
> >> >  
> >> > +if ( dom0_hvm )
> >> > +{
> >> > +domcr_flags |= DOMCRF_hvm |
> >> > +   ((hvm_funcs.hap_supported && !opt_dom0_shadow) ?
> >> > + DOMCRF_hap : 0);
> >> > +config.emulation_flags = XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC;
> >> > +}
> >> 
> >> If you wire this up here already, instead of later in the series, what's
> >> the effect of someone using this option? Crash?
> > 
> > Most certainly. The BSP IP points to 0 at this point. I can wire this up 
> > later, 
> > but it's going to be strange IMHO.
> 
> Not any more "strange" than someone trying the option and getting
> some random and perhaps not immediately understandable crash.

I will add a panic here then, which I will then remove once this is finished.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] arm64: Approach for DT based NUMA and issues

[Julien Grall]

Hi Vijay,

On 28/11/16 15:05, Vijay Kilari wrote:

On Mon, Nov 28, 2016 at 7:20 PM, Andre Przywara  wrote:

On 26/11/16 06:59, Vijay Kilari wrote:


3) Parsing Memory nodes:
--
For all the DT memory nodes in the flattend DT, start address, size
and numa-node-id value is extracted and stored in "node_memblk_range[]"
which is of type struct node.

Each bootinfo.mem entry from UEFI is verified against node_memblk_range[] and
NODE_DATA is populated with start PFN, end PFN and nodeid.

Populating memnodemap:

The memnodemap[] is allocated from heap and using the NODE_DATA structure,
the memnodemap[] is populated with nodeid for each page index.

This memnodemap info is used to fetch memory node id for a given page
by calling phys_to_nid() by memory allocator.

ISSUE: phys_to_nid() is called by memory allocator before memnodemap[]
is initialized.

Since memnodemap[] is allocated from heap, and hence boot allocator should
be initialized. The boot_allocator() needs phys_to_nid() which is not
available untill memnodemap[] is initialized. So there is deadlock situation
during initialization. To overcome this phsy_to_nid() should rely on
node_memblk_range[] to get nodeid untill memnodemap[] is initialized.


What about having an early boot fallback: like:

nodeid_t phys_to_nid(paddr_t addr)
{
if (!memnodemap)
return 0;

}


The memory allocator has all the nodes memory from bootinfo.mem
So, memory allocator fails when phys_to_nid() returns 0 for node 1 memory.


Why don't you allocate memory using the early boot allocator (see 
alloc_boot_pages) as it is done on x86 (see xen/arch/x86/numa.c)?


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 13/19] x86/shadow: Avoid raising faults behind the emulators back

[Andrew Cooper]

On 28/11/16 17:21, Tim Deegan wrote:
>>> I think it would be better to run this check before the 
>>> X86EMUL_UNHANDLEABLE one
>>> and convert injections that we choose not to handle into
>>> X86EMUL_UNHANDLEABLE.
>>>
>>> Which I guess brings us back full circle to the behaviour we had
>>> before, and perhaps the right change to the earlier patch is to
>>> start down this road, with an explanatory comment.
>>>
>>> e.g. start with something like this, immediately after the first call
>>> to x86_emulate():
>>>
>>> /*
>>>  * Events raised within the emulator itself used to return
>>>  * X86EMUL_UNHANDLEABLE because we didn't supply injection
>>>  * callbacks.  Now the emulator supplies those to us via
>>>  * ctxt.event_pending instead.  Preserve the old behaviour
>>>  * for now.
>>>  */
>>>  if (emul_ctxt.ctxt.event_pending)
>>>  r = X86EMUL_UNHANDLEABLE;
>>>
>>> And in this patch, replace it with the hunk you have above, but
>>> setting r = X86EMUL_UNHANDLEABLE instead of injecting #GP.
>>>
>>> Does that make sense?
>> It does make sense, but that goes against the comment of not unshadowing
>> on exception.
> Yep, that comment would need to be updated.  The final behaviour is
> something like what we had before: some kinds of event (#PF in
> particular) get injected, and for the others we unshadow and retry.
> You've expanded the set of events that we'll inject, and the mechanism has
> moved around.

Ok.  I will drop the #GP's and cause this to fall into the unhandleable
path.

>
>> A lot of this revolves around how likely we are to hit the #GP[0] case. 
>> I assert that we shouldn't be able to hit it unless the guest is playing
>> games, or we have a bug in emulation.
>>
>> If we don't go throwing a #GP back, we should at least leave something
>> obvious in the log.
>>
>>> Also, I'm a little confused after all this as to whether the emulator
>>> can still return with X86EMUL_OKAY and the event_pending set.
>> I have now determined this not to be the case.  Apologies for my
>> misinformation in v1.
> Phew!

Yes.  Despite being the last person to fix this several times, it is
very opaque code.

>
>>> This looks like code duplication, but rather than trying to merge the
>>> two cases, I think we can drop this one entirely.  This emulation is
>>> optimistically trying to find the second half of a PAE PTE write -
>>> it's OK just to stop emulating if we hit anything this exciting.
>>> So we can lose the whole hunk.
>> At the very least we should retain the singlestep #DB injection, as it
>> still has trap semantics.
> Argh!  Meaning it returns X86EMUL_EXCEPTION but has already updated
> register state?

Yes

> So yeah, we have to inject that.  But it can go away
> when you change everything to have fault semantics, right?

No.  Singlestep comes out as a hardware exception, not a software interrupt.

Implemented in this way, it is always going to be a special case; we
must manually raise the singlestep event if necessary, as hardware won't
do it automatically on re-entry to the guest.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] access remote xen server using sudo user

[Dario Faggioli]

On Mon, 2016-11-28 at 12:42 +, ganesh kg wrote:
> 
> HI, 
>
Hi,

> i am trying to use sudo user to access xen server remotely. As its
> documented, libvirtd can be accessed only through root user or users
> from libvirtd usergroup.
> 
> is there any tweak or possibility to access libvirt remotely through
> sudo user? or by using certificate?
> 
This is a libvirt question. This mailing list's topic is the
development of the Xen hypervisor (https://xenproject.org/developers/te
ams/hypervisor.html)

I am Cc-ing one of the Xen developers that does a lot of libvirt work,
but I really think that you better contact libvirt specific users or
developers mailing lists:

https://www.redhat.com/mailman/listinfo/libvir-list
https://www.redhat.com/mailman/listinfo/libvirt-users

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RFC] tools/xenlight: Create xenlight Makefile

[Ronald Rojas]

Created basic Makfele for the Golang xenlight
project so that the project is built and
installed. A template template is alo added.
---
 tools/Makefile| 15 +++
 tools/golang/xenlight/Makefile| 29 +
 tools/golang/xenlight/xenlight.go |  7 +++
 3 files changed, 51 insertions(+)
 create mode 100644 tools/golang/xenlight/Makefile
 create mode 100644 tools/golang/xenlight/xenlight.go

diff --git a/tools/Makefile b/tools/Makefile
index 71515b4..b89f06b 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -11,6 +11,7 @@ SUBDIRS-y += misc
 SUBDIRS-y += examples
 SUBDIRS-y += hotplug
 SUBDIRS-y += xentrace
+SUBDIRS-y += golang/xenlight
 SUBDIRS-$(CONFIG_XCUTILS) += xcutils
 SUBDIRS-$(CONFIG_X86) += firmware
 SUBDIRS-y += console
@@ -311,6 +312,20 @@ subdir-install-debugger/gdbsx: .phony
 subdir-all-debugger/gdbsx: .phony
$(MAKE) -C debugger/gdbsx all
 
+subdir-all-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight all
+
+subdir-clean-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight clean
+
+subdir-install-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight install
+
+subdir-build-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight build
+
+subdir-distclean-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight distclean
 
 subdir-clean-debugger/kdd subdir-distclean-debugger/kdd: .phony
$(MAKE) -C debugger/kdd clean
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
new file mode 100644
index 000..c723c1d
--- /dev/null
+++ b/tools/golang/xenlight/Makefile
@@ -0,0 +1,29 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+BINARY = xenlightgo
+GO = go
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: xenlight
+
+.PHONY: install
+install: build
+   [ -f $(BINARY) ] || $(INSTALL_PROG) xenlight.go $(DESTDIR)$(bindir)
+
+.PHONY: clean
+clean:
+   $(RM) $(BINARY)
+
+.PHONY: distclean
+distclean: clean
+
+
+xenlight: xenlight.go
+   $(GO) build -o $(BINARY) xenlight.go
+
+
+-include $(DEPS)
diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
new file mode 100644
index 000..50e8d8d
--- /dev/null
+++ b/tools/golang/xenlight/xenlight.go
@@ -0,0 +1,7 @@
+package main
+
+import "fmt"
+
+func main() {
+   fmt.Println("vim-go")
+}
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 13/19] x86/shadow: Avoid raising faults behind the emulators back

[Tim Deegan]

At 16:04 + on 28 Nov (1480349059), Andrew Cooper wrote:
> On 28/11/16 14:49, Tim Deegan wrote:
> > At 11:13 + on 28 Nov (1480331610), Andrew Cooper wrote:
> >> +/*
> >> + * This emulation covers writes to shadow pagetables.  We 
> >> tolerate #PF
> >> + * (from hitting adjacent pages), #GP/#SS (from segmentation 
> >> errors),
> >> + * and #DB (from singlestepping).  Anything else is an emulation 
> >> bug,
> >> + * or a guest playing with the instruction stream under Xen's 
> >> feet.
> >> + */
> >> +if ( emul_ctxt.ctxt.event.type == X86_EVENTTYPE_HW_EXCEPTION &&
> >> + (emul_ctxt.ctxt.event.vector < 32) &&
> >> + ((1u << emul_ctxt.ctxt.event.vector) &
> >> +  ((1u << TRAP_debug) | (1u << TRAP_stack_error) |
> >> +   (1u << TRAP_gp_fault) | (1u << TRAP_page_fault))) )
> >> +{
> >> +if ( is_hvm_vcpu(v) )
> >> +hvm_inject_event(_ctxt.ctxt.event);
> >> +else
> >> +pv_inject_event(_ctxt.ctxt.event);
> >> +}
> >> +else
> >> +{
> >> +if ( is_hvm_vcpu(v) )
> >> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> >> +else
> >> +pv_inject_hw_exception(TRAP_gp_fault, 0);
> >> +}
> > I don't think it's OK to lob #GP into a HVM guest here -- we can hit
> > this path even if the guest isn't behaving strangely.
> 
> What circumstances are you thinking of?
> 
> Unless the guest is playing with the instruction stream,  event_pending
> will only be set by the set in the paths altered by this patch, which is
> the four whitelisted vectors.

I don't see any path through the emulator that both writes to memory
and raises a different exception to these four, so I retract that -
the guest does have to be acting strangely.  Likely either modifying
code while another CPU is running on it or executing from a page whose
PT mappings are changing (including changing a text mapping and then
executing from it without flushing TLB first).

But even if the guest is doing something demented with multithreaded
self-modifying code, I think we're better off abandoning ship here
and retrying the instruction than raising a spurious #GP.  HVM
guests don't have any contract with us that lets us #GP them here.
And we can hit this path for writes to non-pagetables, if we haven't
unshadowed an ex-pagetable yet.

I don't know of any kernel-space code that behaves quite so loosely
wiht its mappings, but obfuscation tricks to stop reverse engineering
can do some pretty strange things.

> > I think it would be better to run this check before the 
> > X86EMUL_UNHANDLEABLE one
> > and convert injections that we choose not to handle into
> > X86EMUL_UNHANDLEABLE.
> >
> > Which I guess brings us back full circle to the behaviour we had
> > before, and perhaps the right change to the earlier patch is to
> > start down this road, with an explanatory comment.
> >
> > e.g. start with something like this, immediately after the first call
> > to x86_emulate():
> >
> > /*
> >  * Events raised within the emulator itself used to return
> >  * X86EMUL_UNHANDLEABLE because we didn't supply injection
> >  * callbacks.  Now the emulator supplies those to us via
> >  * ctxt.event_pending instead.  Preserve the old behaviour
> >  * for now.
> >  */
> >  if (emul_ctxt.ctxt.event_pending)
> >  r = X86EMUL_UNHANDLEABLE;
> >
> > And in this patch, replace it with the hunk you have above, but
> > setting r = X86EMUL_UNHANDLEABLE instead of injecting #GP.
> >
> > Does that make sense?
> 
> It does make sense, but that goes against the comment of not unshadowing
> on exception.

Yep, that comment would need to be updated.  The final behaviour is
something like what we had before: some kinds of event (#PF in
particular) get injected, and for the others we unshadow and retry.
You've expanded the set of events that we'll inject, and the mechanism has
moved around.

> A lot of this revolves around how likely we are to hit the #GP[0] case. 
> I assert that we shouldn't be able to hit it unless the guest is playing
> games, or we have a bug in emulation.
> 
> If we don't go throwing a #GP back, we should at least leave something
> obvious in the log.
> 
> >
> > Also, I'm a little confused after all this as to whether the emulator
> > can still return with X86EMUL_OKAY and the event_pending set.
> 
> I have now determined this not to be the case.  Apologies for my
> misinformation in v1.

Phew!

> > This looks like code duplication, but rather than trying to merge the
> > two cases, I think we can drop this one entirely.  This emulation is
> > optimistically trying to find the second half of a PAE PTE write -
> > it's OK just to stop emulating if we hit anything this exciting.
> > So we can lose the whole hunk.
> 
> At the very least we should retain the singlestep #DB injection, as it
> 

Re: [Xen-devel] Payed Xen Admin

[Michael Schinzel]

Hello,

thank you for your response. There are no quemu prozesses which we can identify 
with the ID of the failed guest.


Mit freundlichen Grüßen

Michael Schinzel
- Geschäftsführer -

[https://www.ip-projects.de/logo_mail.png]

IP-Projects GmbH & Co. KG
Am Vogelherd 14
D - 97295 Waldbrunn

Telefon: 09306 - 76499-0
FAX: 09306 - 76499-15
E-Mail: i...@ip-projects.de

Geschäftsführer: Michael Schinzel
Registergericht Würzburg: HRA 6798
Komplementär: IP-Projects Verwaltungs GmbH



Von: Neil Sikka [mailto:neilsi...@gmail.com]
Gesendet: Montag, 28. November 2016 14:30
An: Michael Schinzel 
Cc: Xen-devel 
Betreff: Re: [Xen-devel] Payed Xen Admin


Usually, I've seen (null) domains are not running but their Qemu DMs are 
running. You could probably remove the (null) from the list by using "kill -9" 
on the qemu pids.

On Nov 27, 2016 11:55 PM, "Michael Schinzel" 
> wrote:
Good Morning,

we have some issues with our Xen Hosts. It seems it is a xen bug but we do not 
find the solution.

NameID   Mem VCPUs  State   Time(s)
Domain-0 0 16192 4 r-  147102.5
(null)   2 1 1 --p--d1273.2
vmanager2268 4  1024 1 -b   34798.8
vmanager2340 5  1024 1 -b5983.8
vmanager261912   512 1 -b1067.0
vmanager261813  1024 4 -b1448.7
vmanager255714  1024 1 -b2783.5
vmanager187116   512 1 -b3772.1
vmanager259217   512 1 -b   19744.5
vmanager256618  2048 1 -b3068.4
vmanager222819   512 1 -b 837.6
vmanager224120   512 1 -b 997.0
vmanager224421  2048 1 -b1457.9
vmanager227222  2048 1 -b1924.5
vmanager222623  1024 1 -b1454.0
vmanager224524   512 1 -b 692.5
vmanager224925   512 1 -b   22857.7
vmanager226526  2048 1 -b1388.1
vmanager227027   512 1 -b1250.6
vmanager227128  2048 3 -b2060.8
vmanager227329  1024 1 -b   34089.4
vmanager227430  2048 1 -b8585.1
vmanager228131  2048 2 -b1848.9
vmanager228232   512 1 -b 755.1
vmanager228833  1024 1 -b 543.6
vmanager229234   512 1 -b3004.9
vmanager204135   512 1 -b4246.2
vmanager221636  1536 1 -b   47508.3
vmanager229537   512 1 -b1414.9
vmanager259938  1024 4 -b7523.0
vmanager229639  1536 1 -b7142.0
vmanager229740   512 1 -b 536.7
vmanager213642  1024 1 -b6162.9
vmanager229843   512 1 -b 441.7
vmanager229944   512 1 -b 368.7
(null)  45 4 1 --p--d1296.3
vmanager230346   512 1 -b1437.0
vmanager230847   512 1 -b 619.3
vmanager231848   512 1 -b 976.8
vmanager232549   512 1 -b 480.2
vmanager262053   512 1 -b 346.2
(null)  56 0 1 --p--d   8.8
vmanager233457   512 1 -b 255.5
vmanager223558   512 1 -b1724.2
vmanager987 59   512 1 -b 647.1
vmanager230260   512 1 -b 171.4
vmanager233561   512 1 -b 

Re: [Xen-devel] some thoughts about merlot{0|1} issues [was: Re: [xen-unstable test] 102522: tolerable FAIL - PUSHED]

[Dario Faggioli]

On Mon, 2016-11-28 at 08:48 -0500, Boris Ostrovsky wrote:
> On 11/24/2016 10:31 AM, Jan Beulich wrote:
> > 
> > This indeed looks surprising for a half way modern system - is the
> > BIOS perhaps limiting C-states (maybe instructed to via BIOS
> > setup)?
> 
> IIRC some BIOSes indeed provided an option to disable C2. Dumping
> SSDT
> would tell us whether C2 is there is BIOS is not accessible.
> 
I will try to extract that.

In any case, what I'm wondering is, could this ACPI / PM thing be
linked to the behavior we are seeing?

I'm not sure I see how... perhaps the system gets too hot and its
throttled down? (Yes, shooting in the dark, I know.)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] (no subject)

[Ronald Rojas]

Create a Makefile for the golang xenlight project, which will
allow users to access libxl functionality in Golang. Makefile 
rules were also added to tools/Makefile for the project to be 
built and installed. A template Golang file was also created 
for the project to be properly built. 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Julien Grall]

On 28/11/16 17:11, Andrew Cooper wrote:

On 28/11/16 16:59, Julien Grall wrote:

Hi,

On 28/11/16 15:43, Oleksandr Andrushchenko wrote:

On 11/28/2016 05:00 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:56, Oleksandr Andrushchenko wrote:

On 11/28/2016 04:24 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:12, Oleksandr Andrushchenko wrote:


On 11/28/2016 03:27 PM, Jan Beulich wrote:

+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page
describing
+ *   page directory. Must be 0 if no more pages in the list.


If I am not mistaken 0 is a valid grant.


Then I will remove this sentence, anyways BE knows how many grefs
there
are for the buffer size given

BTW, xen-blkfrint.c:
#define GRANT_INVALID_REF0
this is from where I got "Must be 0 if no more pages in the list."


GRANT_INVALID_REF is internally to Linux and never exposed in the PV
driver. So for me it is implementation details because ref 0 could be
allocated (log dump by Xen):

(XEN)    active     shared 
(XEN) [ref] localdom mfn  pin  localdom gmfn flags
(XEN) grant-table for remote domain:2 (v1)
(XEN) [  0]0 0x99bf35 0x0001  0 0x039000 0x19
(XEN) [  1]0 0x99bf33 0x0001  0 0x039001 0x19


Grant reference 0 is reserved in the ABI for the paravirtual console.


Oh, so considering grant ref 0 as invalid in a PV protocol would be fine?

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Andrew Cooper]

On 28/11/16 16:59, Julien Grall wrote:
> Hi,
>
> On 28/11/16 15:43, Oleksandr Andrushchenko wrote:
>> On 11/28/2016 05:00 PM, Julien Grall wrote:
>>> Hi Oleksandr,
>>>
>>> On 28/11/16 14:56, Oleksandr Andrushchenko wrote:
 On 11/28/2016 04:24 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 28/11/16 14:12, Oleksandr Andrushchenko wrote:
>>
>> On 11/28/2016 03:27 PM, Jan Beulich wrote:
 + *
 + * gref_dir_next_page - grant_ref_t, reference to the next page
 describing
 + *   page directory. Must be 0 if no more pages in the list.
>
> If I am not mistaken 0 is a valid grant.
>
 Then I will remove this sentence, anyways BE knows how many grefs
 there
 are for the buffer size given
>> BTW, xen-blkfrint.c:
>> #define GRANT_INVALID_REF0
>> this is from where I got "Must be 0 if no more pages in the list."
>
> GRANT_INVALID_REF is internally to Linux and never exposed in the PV
> driver. So for me it is implementation details because ref 0 could be
> allocated (log dump by Xen):
>
> (XEN)    active     shared 
> (XEN) [ref] localdom mfn  pin  localdom gmfn flags
> (XEN) grant-table for remote domain:2 (v1)
> (XEN) [  0]0 0x99bf35 0x0001  0 0x039000 0x19
> (XEN) [  1]0 0x99bf33 0x0001  0 0x039001 0x19

Grant reference 0 is reserved in the ABI for the paravirtual console.

This reuse looks erroneous on behalf of blkfront.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] some thoughts about merlot{0|1} issues [was: Re: [xen-unstable test] 102522: tolerable FAIL - PUSHED]

[Dario Faggioli]

On Mon, 2016-11-28 at 17:45 +0100, Dario Faggioli wrote:
> On Mon, 2016-11-28 at 10:16 -0500, Konrad Rzeszutek Wilk wrote:
> > 
> > Dario, lastly - did you have xen-acpi-processor loaded or built in
> > your kernel?
> > 
> I'm sure it's there.
> 
And I was right, it is there:

root@merlot1:~# zcat /proc/config.gz |grep -i xen_acpi
CONFIG_XEN_ACPI_PROCESSOR=m

But it's not loaded:

root@merlot1:~# lsmod |grep xen
xen_gntalloc3632  0

And if I try to load it, here's what happens:

root@merlot1:~# modprobe xen-acpi-processor
modprobe: ERROR: could not insert 'xen_acpi_processor': No such device

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Julien Grall]

Hi,

On 28/11/16 15:43, Oleksandr Andrushchenko wrote:

On 11/28/2016 05:00 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:56, Oleksandr Andrushchenko wrote:

On 11/28/2016 04:24 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:12, Oleksandr Andrushchenko wrote:


On 11/28/2016 03:27 PM, Jan Beulich wrote:

+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page
describing
+ *   page directory. Must be 0 if no more pages in the list.


If I am not mistaken 0 is a valid grant.


Then I will remove this sentence, anyways BE knows how many grefs there
are for the buffer size given

BTW, xen-blkfrint.c:
#define GRANT_INVALID_REF0
this is from where I got "Must be 0 if no more pages in the list."


GRANT_INVALID_REF is internally to Linux and never exposed in the PV 
driver. So for me it is implementation details because ref 0 could be 
allocated (log dump by Xen):


(XEN)    active     shared 
(XEN) [ref] localdom mfn  pin  localdom gmfn flags
(XEN) grant-table for remote domain:2 (v1)
(XEN) [  0]0 0x99bf35 0x0001  0 0x039000 0x19
(XEN) [  1]0 0x99bf33 0x0001  0 0x039001 0x19


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.5-testing test] 102690: regressions - FAIL

[osstest service owner]

flight 102690 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102690/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101275

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu  6 xen-bootfail in 102683 pass in 102690
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 102683 
pass in 102690
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 102683 pass 
in 102690
 test-amd64-amd64-xl-multivcpu  9 debian-installfail pass in 102683
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
102683

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt 14 guest-saverestore   fail in 102683 like 101275
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail in 102683 like 101275
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101258
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 101275
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101275
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101275
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101275

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5 18 xtf/test-hvm32-cpuid-faulting fail in 102683 never 
pass
 test-xtf-amd64-amd64-5 27 xtf/test-hvm32pae-cpuid-faulting fail in 102683 
never pass
 test-xtf-amd64-amd64-3 18 xtf/test-hvm32-cpuid-faulting fail in 102683 never 
pass
 test-xtf-amd64-amd64-3 27 xtf/test-hvm32pae-cpuid-faulting fail in 102683 
never pass
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pse-cpuid-faulting fail in 102683 
never pass
 test-xtf-amd64-amd64-3 37 xtf/test-hvm64-cpuid-faulting fail in 102683 never 
pass
 test-xtf-amd64-amd64-3 49 xtf/test-pv32pae-cpuid-faulting fail in 102683 never 
pass
 test-xtf-amd64-amd64-3 57 xtf/test-pv64-cpuid-faulting fail in 102683 never 
pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pse-cpuid-faulting fail in 102683 
never pass
 test-xtf-amd64-amd64-5 37 xtf/test-hvm64-cpuid-faulting fail in 102683 never 
pass
 test-xtf-amd64-amd64-5 49 xtf/test-pv32pae-cpuid-faulting fail in 102683 never 
pass
 test-xtf-amd64-amd64-5 57 xtf/test-pv64-cpuid-faulting fail in 102683 never 
pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-4 27 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-xtf-amd64-amd64-4 33 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2  49 xtf/test-pv32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   57 xtf/test-pv64-cpuid-faulting fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start   

Re: [Xen-devel] some thoughts about merlot{0|1} issues [was: Re: [xen-unstable test] 102522: tolerable FAIL - PUSHED]

[Dario Faggioli]

On Mon, 2016-11-28 at 10:16 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2016 at 08:48:30AM -0500, Boris Ostrovsky wrote:
> > IIRC some BIOSes indeed provided an option to disable C2. Dumping
> > SSDT
> > would tell us whether C2 is there is BIOS is not accessible.
> 
> Dario, lastly - did you have xen-acpi-processor loaded or built in
> your kernel?
>
I'm sure it's there.

In fact, this is an OSSTest box in the colo. I've  tried have a look
right now, without taking it off from OSSTest, but it does not have Xen
installed yet (I don't know what job it's executing).

Anyway, when the tests run, the kernel in use is the one build for all
the various tests and boxes of a flight, and it does has
XEN_ACPI_PROCESSOR. That's why I'm saying that I am sure it is there.

Anyway, I'll double check that.

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.8] tools/libacpi: Fix compilation when cross building the tools

[Andrii Anisov]

> I diffed the generated dsdt and it is the same before and after the
> patches when built natively. I did try cross-build, Andrii could you
> give a try?
Build passed smoothly.
Non-ACPI guests started well.

Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 68114: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68114 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68114/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4e3b05a49f454bc257252ae9090421e3c8447737
baseline version:
 ovmf 418373a1cd97abc0c0e3557f7a00105291829e6f

Last test of basis68112  2016-11-28 07:25:07 Z0 days
Testing same since68114  2016-11-28 14:19:32 Z0 days1 attempts


People who touched revisions under test:
  Eric Dong 
  Liming Gao 
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 4e3b05a49f454bc257252ae9090421e3c8447737
Author: Star Zeng 
Date:   Wed Nov 23 15:28:38 2016 +0800

SecurityPkg Tcg2ConfigDxe: Remove BlockSID actions and related strings

Tcg2ConfigDxe has no related code to handle BlockSID related actions
that have been covered by OpalPasswordDxe driver.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Eric Dong 

commit 34c2ce65291081241abc995438f3b89da65d1294
Author: Eric Dong 
Date:   Thu Jun 2 15:20:17 2016 +0800

SecurityPkg OpalPasswordDxe: Use PP actions to enable BlockSID

Update the implementation to use PP BlockSID related actions.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit e92ddda2b547f0b952935abaf44fd72e97dbf755
Author: Star Zeng 
Date:   Wed Nov 23 16:38:33 2016 +0800

SecurityPkg Tcg2PPLib: Support BlockSID related actions

Then Tcg2PhysicalPresenceLib can support TCG2 PP TPM2,
storage management and vendor specific requests according
to Physical Presence Interface Specification.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Eric Dong 

commit 6a82ceb69093cf77ac36dff63225c05f764999ca
Author: Liming Gao 
Date:   Wed Nov 23 15:03:08 2016 +0800

MdePkg IndustryStandard: Add DDR3, DDR4 and LPDDR definition per SPD spec

https://bugzilla.tianocore.org/show_bug.cgi?id=201

In V3, Use Odt to replace ODT, Cke to replace CKE, Id to replace ID,
and Cl to replace CL in structure field name.

In V2, separate DDR3, DDR4 and LPDDR definition into the different files;
use the different SPD prefix as structure definitions for each SPD type.

Cc: Giri P Mudusuru 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Giri P Mudusuru 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 17/19] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

[Tim Deegan]

At 16:32 + on 28 Nov (1480350762), Andrew Cooper wrote:
> On 28/11/16 14:56, Tim Deegan wrote:
> > At 11:13 + on 28 Nov (1480331614), Andrew Cooper wrote:
> >> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require 
> >> callers
> >> to inject the pagefault themselves.
> > This seems like it'd be easy to forget to DTRT with the fault,
> > especially in code being ported forward across this series.
> 
> Code ported across the series will have an API change to accommodate.
> 
> >
> > Would it be better to have hvm_copy  take a callback function
> > instead of a pfinfo pointer?
> 
> I considered both of these options, but this option seemed cleaner at
> the time.
> 
> I am not fussed either way, but I don't see that a new function pointer
> would be any less easy to get wrong.

Righto.  As I said, Ack to the shadow bits anyway.

Tim.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 17/19] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

[Andrew Cooper]

On 28/11/16 14:56, Tim Deegan wrote:
> At 11:13 + on 28 Nov (1480331614), Andrew Cooper wrote:
>> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
>> to inject the pagefault themselves.
> This seems like it'd be easy to forget to DTRT with the fault,
> especially in code being ported forward across this series.

Code ported across the series will have an API change to accommodate.

>
> Would it be better to have hvm_copy  take a callback function
> instead of a pfinfo pointer?

I considered both of these options, but this option seemed cleaner at
the time.

I am not fussed either way, but I don't see that a new function pointer
would be any less easy to get wrong.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Julien Grall]

Hi Oleksandr,

On 28/11/16 15:43, Oleksandr Andrushchenko wrote:

On 11/28/2016 05:00 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:56, Oleksandr Andrushchenko wrote:

On 11/28/2016 04:24 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:12, Oleksandr Andrushchenko wrote:


On 11/28/2016 03:27 PM, Jan Beulich wrote:

+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page
describing
+ *   page directory. Must be 0 if no more pages in the list.


If I am not mistaken 0 is a valid grant.


Then I will remove this sentence, anyways BE knows how many grefs there
are for the buffer size given

BTW, xen-blkfrint.c:
#define GRANT_INVALID_REF0
this is from where I got "Must be 0 if no more pages in the list."

+ * gref[i] - grant_ref_t, reference to a shared page of the buffer
+ *   allocated at XENSND_OP_OPEN
+ *
+ * Number of grant_ref_t entries in the whole page directory is not
+ * passed, but instead can be calculated as:
+ *   num_grefs_total = DIV_ROUND_UP(XENSND_OP_OPEN.buffer_sz,
PAGE_SIZE);

The header should be self contained, and there's no DIV_ROUND_UP()
anywhere under public/io/ for a reader to refer to. Please express
this
using mathematical terms plus, if needed, standard C library ones.

done, will put:
num_grefs_total = (XENSND_OP_OPEN.buffer_sz + PAGE_SIZE - 1) /
PAGE_SIZE


Can we avoid to use PAGE_SIZE in the header? Xen, the front-end and
the back-end may have different page size.


then, I believe, the protocol should implement something like blkif
does?
Multi-page buffer which depends on front and back page sizes?
(blkif: max-ring-page-order/ring-ref%u/ring-page-order)
Is this what you mean?


It is not what I meant. I asked to define PAGE_SIZE. Is it the the
PAGE_SIZE of Xen? PAGE_SIZE of the backend? PAGE_SIZE of the frontend?

Currently PV driver PAGE_SIZE is based on the size of a grant page.

As per my understanding, I can put XEN_PAGE_SIZE here, because
xen/page.h says:
" * We assume that PAGE_SIZE is a multiple of XEN_PAGE_SIZE
 * XXX: Add a BUILD_BUG_ON?
"
meaning that PAGE_SIZE on either side cannot be less than XEN_PAGE_SIZE
Will XEN_PAGE_SIZE fit then?


Yes. FWIW, this is the page granularity used by every PV drivers.

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services

[Toomas Soome]

> On 28. nov 2016, at 17:46, Daniel Kiper  wrote:
> 
> Hi Toomas,
> 
> Thank you for comments.
> 
> On Thu, Nov 24, 2016 at 11:47:48PM +0200, Toomas Soome wrote:
>> There is still the same confusion as with entry address tag 7; the diagram 
>> has
> 
> I suppose that you thought about tag type 3.
> 

Yes, sorry:)

>> u_virt, yet the text does claim it is physical address. Sure, it is assumed 
>> the
>> identity mapping, but still those names are creating confusion.
> 
> If yes then I agree that u_virt should be changed to u_phys. Though maybe in
> longterm we should define tags for every architecture separately with types
> specific for a given architecture. Then we should avoid most of such 
> confusions.
> I hope…
> 
>> Moreover, the EFI32 and EFI64 have different address sizes (32 versus 64 
>> bit),
>> yet there is the same type: u_virt - so it hints the upper part of the 64bit
>> address is ignored, but its not really clear from the text???
> 
> It is clear that it should be u_phys or u32 for EFI i386. Though I am not sure
> about EFI amd64 right now. Potentially it could be u64. However, I assume (at
> least right now; and current GRUB implementation works in that way) that the 
> boot
> loader cannot put any part of an image higher than 4 GiB - 1 (well, I agree 
> that
> it should be mentioned in spec). Even on EFI amd64 platform. This is because 
> still
> some of the image boot code can be executed in 32-bit mode. We have such 
> situation
> in Xen. So, from this point of view 32-bit entry_addr in tag type 9 is 
> sufficient.
> Though I can agree that we should anticipate support for full 64-bit images.
> I think that it is possible (but not implemented yet). We should add to spec 
> tag
> which says: yes, I am 64-bit image. Then the image may provide relevant 64-bit
> equivalent tags (defined properly in spec). So, in this case we should have 
> in spec
> another EFI amd64 tag which has 64-bit entry_addr. This way various boot code 
> types
> (32-bit and 64-bit) may coexist without any issue in one image and boot 
> loader may
> choose supported one. Does it make sense?
> 
> Daniel


Well, yes, I know about 4GB practical limit, and thats why I think it’s ok to 
use 32bit address there - just I wanted to point out that it may be good idea 
to have it explicitly noted.

rgds,
toomas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] some thoughts about merlot{0|1} issues [was: Re: [xen-unstable test] 102522: tolerable FAIL - PUSHED]

[Jan Beulich]

>>> On 28.11.16 at 17:08,  wrote:
> On 28/11/16 15:16, Konrad Rzeszutek Wilk wrote:
>> On Mon, Nov 28, 2016 at 08:48:30AM -0500, Boris Ostrovsky wrote:
>>> On 11/24/2016 10:31 AM, Jan Beulich wrote:
>>> On 24.11.16 at 16:14,  wrote:
> When dumping ACPI C states, here's how things look like for _all_ CPUs:
> Nov 23 13:13:00.382134 (XEN) ==cpu3==
> Nov 23 13:13:00.382157 (XEN) active state:C-1
> Nov 23 13:13:00.390096 (XEN) max_cstate:  C7
> Nov 23 13:13:00.390125 (XEN) states:
> Nov 23 13:13:00.390148 (XEN) C1:  type[C1] latency[000] 
> usage[] 
> method[ HALT] duration[0]
> Nov 23 13:13:00.398055 (XEN) C0:  usage[] 
> duration[4229118701384]
> Nov 23 13:13:00.398090 (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
> Nov 23 13:13:00.406088 (XEN) CC3[0] CC6[0] CC7[0]
>
> And I checked other runs, and it's the same everywhere.
>
> I remember that Jan suggested trying to pass max_cstate=1 to Xen at
> boot. I was about to ask Ian to do that for this host, but it looks
> like we're using only C0 and C1 already anyway.
 This indeed looks surprising for a half way modern system - is the
 BIOS perhaps limiting C-states (maybe instructed to via BIOS setup)?
>>>
>>> IIRC some BIOSes indeed provided an option to disable C2. Dumping SSDT
>>> would tell us whether C2 is there is BIOS is not accessible.
>> Keep in mind that not all C states are exposed if MWAIT is not exposed
>> to dom0 (see xen_check_mwait in arch/x86/xen/enlighten.c).
>>
>> I recall some emails from Andrew about the CPU faulting and his CPUID
>> patches inhibiting this but it may very well be fixed?
> 
> merlot is AMD hardware, so no faulting.
> 
> Also, Xen purposefully leaks EIST into the control domain kernel to work
> around that particular Linux bug.

Isn't EIST an Intel-only thing?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

[Julien Grall]

On 24/11/16 21:10, Volodymyr Babchuk wrote:

Hello all,


Hello,


My name is Volodymyr Babchuk, I'm working on EPAM Systems with bunch
of other guys like Artem Mygaiev or Andrii Anisov. My responsibility
there is security in embedded systems.

I would like to discuss approaches to OP-TEE support in XEN.


Thank you for sharing this, I am CC-ing some people who showed interest 
on accessing trusted firmware from the guest.


In the future, please try to CC relevant people (in this case ARM 
maintainers) to avoid any delay on the answer.



But first small introduction for those who is not familiar with topic:

There are such thing as Security Extensions for ARM cores. It is part
of bigger thing - ARM TrustZone. Security extensions allows CPU to
work in two states: Normal (Non-Secure) and Secure.
Other parts of TrustZone provide hardware protection for peripherals,
memory regions, etc. So, when CPU is running in secure state, it have
access to all peripherals and memories, also it can forbid access to
some of those resources from Normal state. Secure state have own
Supervisor and User modes, so we can run OS there.
Just to be clear, CPU can run in following modes; user, supervisor,
hypervisor, secure monitor, secure user and secure supervisor. Last
two basically are the same as normal USR and SVC, but in secure state.
And Secure Monitor is special mode, that can switch Secure state to
Non-secure state and back. SMC instruction takes into this mode.
So, we can run one OS in secure state and one in non-secure state.
They will be mostly independent from each other. In normal
(non-secure) mode we run, say, Linux. And in Secure mode we run some
Trusted OS (or Secure Os). Secure OS provides services like
cryptography, secure storage, DRM, virtual SIM, etc. to Normal world
OS (it also called "Rich OS". It can be Linux for example.).
There are standard created by GlobalPlatform that is called "Trusted
Execution Environment" (TEE). It defines requirements and APIs for the
Secure OS. There are number number of Secure OSes that tries to be
conform with TEE specification and OP-TEE is one of them.

CPU is normally running in Non-Secure state. When normal world OS
needs some services from Secure OS, it issues SMC instruction with
command data. This instruction puts processor into Secure Monitor
Mode, where secure monitor code examines request. If it is request to
Secure OS, it switches processor to Secure Supervisor mode and passes
request to Secure OS. When Secure OS finishes work, it also issues SMC
instruction and Secure Monitor switches processor back to non-secure
state, returning control to Rich OS.
SMC instruction can be used not only to communicate with SecureOS, but
also for other services like power control, control of processor
cores, etc. ARM wrote document "SMC Calling Convention" which in
detail describes how this instruction can be used.  By the way, SMCCC
requires to pass Virtual Machine ID in one of the registers during SMC
call.

Now let's get back to XEN. We want XEN to provide TEE services to Dom0
and guests. I can see different approaches to this:

 - One of them I call "Emulated TEE". Guests does not have access to
real TEE OS. Instead somewhere (in Dom0) we run instance of TEE for
each of the Guests. This provides perfect isolation, as TEE instances
does not anything about each one. But we will miss all hardware
benefits like cryptographic acceleration.
 - Another way is to allow guests to work with real TEE running Secure
state. In this case TEE should be aware about guests to track shared
memories, opened sessions, etc. It requires some careful programming
to ensure that guest belongings are isolated from each other. But as
reward we are much closer to original TrustZone desing.

Personally I prefer second approach. I, even, did small PoC that
allows different guests to work with OP-TEE (but not simultaneously!).


I agree that the first approach is not good because you can't get 
advantage of the hardware. However, I have some concerns about the 
second (see below).


Bear in mind that I don't know much about TEE :).


You can find patches at [1] if you are interested.
During working on this PoC I have identified main questions that
should be answered:

On XEN side:
1. SMC handling in XEN. There are many different SMCs and only portion
of them belong to TEE. We need some SMC dispatcher that will route
calls to different subsystems. Like PSCI calls to PSCI subsystem, TEE
calls to TEE subsystem.


So from my understanding of this paragraph, all SMC TEE calls should 
have a guest ID in the command. We don't expect command affecting all 
TEE. Correct?




2. Support for different TEEs. There are OP-TEE, Google Trusty, TI
M-Shield... They all work thru SMC, but have different protocols.
Currently, we are aimed only to OP-TEE. But we need some generic API
in XEN, so support for new TEE can be easily added.

For instance you

Is there any  generic way to detect which TEE is been in used and the 

Re: [Xen-devel] some thoughts about merlot{0|1} issues [was: Re: [xen-unstable test] 102522: tolerable FAIL - PUSHED]

[Andrew Cooper]

On 28/11/16 15:16, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 28, 2016 at 08:48:30AM -0500, Boris Ostrovsky wrote:
>> On 11/24/2016 10:31 AM, Jan Beulich wrote:
>> On 24.11.16 at 16:14,  wrote:
 When dumping ACPI C states, here's how things look like for _all_ CPUs:
 Nov 23 13:13:00.382134 (XEN) ==cpu3==
 Nov 23 13:13:00.382157 (XEN) active state: C-1
 Nov 23 13:13:00.390096 (XEN) max_cstate:   C7
 Nov 23 13:13:00.390125 (XEN) states:
 Nov 23 13:13:00.390148 (XEN) C1:   type[C1] latency[000] 
 usage[] method[ HALT] duration[0]
 Nov 23 13:13:00.398055 (XEN) C0:   usage[] 
 duration[4229118701384]
 Nov 23 13:13:00.398090 (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
 Nov 23 13:13:00.406088 (XEN) CC3[0] CC6[0] CC7[0]

 And I checked other runs, and it's the same everywhere.

 I remember that Jan suggested trying to pass max_cstate=1 to Xen at
 boot. I was about to ask Ian to do that for this host, but it looks
 like we're using only C0 and C1 already anyway.
>>> This indeed looks surprising for a half way modern system - is the
>>> BIOS perhaps limiting C-states (maybe instructed to via BIOS setup)?
>>
>> IIRC some BIOSes indeed provided an option to disable C2. Dumping SSDT
>> would tell us whether C2 is there is BIOS is not accessible.
> Keep in mind that not all C states are exposed if MWAIT is not exposed
> to dom0 (see xen_check_mwait in arch/x86/xen/enlighten.c).
>
> I recall some emails from Andrew about the CPU faulting and his CPUID
> patches inhibiting this but it may very well be fixed?

merlot is AMD hardware, so no faulting.

Also, Xen purposefully leaks EIST into the control domain kernel to work
around that particular Linux bug.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 13/19] x86/shadow: Avoid raising faults behind the emulators back

[Andrew Cooper]

On 28/11/16 14:49, Tim Deegan wrote:
> Hi,
>
> At 11:13 + on 28 Nov (1480331610), Andrew Cooper wrote:
>> Use x86_emul_{hw_exception,pagefault}() rather than
>> {pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
>> faults to be known to the emulator.  This requires altering the callers of
>> x86_emulate() to properly re-inject the event.
>>
>> While fixing this, fix the singlestep behaviour.  Previously, an otherwise
>> successful emulation would fail if singlestepping was active, as the emulator
>> couldn't raise #DB.  This is unreasonable from the point of view of the 
>> guest.
>>
>> We therefore tolerate #PF/#GP/SS and #DB being raised by the emulator, but
>> reject anything else as unexpected.
>>
>> Signed-off-by: Andrew Cooper 
>> +if ( r == X86EMUL_EXCEPTION && emul_ctxt.ctxt.event_pending )
>> +{
>> +/*
>> + * This emulation covers writes to shadow pagetables.  We tolerate 
>> #PF
>> + * (from hitting adjacent pages), #GP/#SS (from segmentation 
>> errors),
>> + * and #DB (from singlestepping).  Anything else is an emulation 
>> bug,
>> + * or a guest playing with the instruction stream under Xen's feet.
>> + */
>> +if ( emul_ctxt.ctxt.event.type == X86_EVENTTYPE_HW_EXCEPTION &&
>> + (emul_ctxt.ctxt.event.vector < 32) &&
>> + ((1u << emul_ctxt.ctxt.event.vector) &
>> +  ((1u << TRAP_debug) | (1u << TRAP_stack_error) |
>> +   (1u << TRAP_gp_fault) | (1u << TRAP_page_fault))) )
>> +{
>> +if ( is_hvm_vcpu(v) )
>> +hvm_inject_event(_ctxt.ctxt.event);
>> +else
>> +pv_inject_event(_ctxt.ctxt.event);
>> +}
>> +else
>> +{
>> +if ( is_hvm_vcpu(v) )
>> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
>> +else
>> +pv_inject_hw_exception(TRAP_gp_fault, 0);
>> +}
> I don't think it's OK to lob #GP into a HVM guest here -- we can hit
> this path even if the guest isn't behaving strangely.

What circumstances are you thinking of?

Unless the guest is playing with the instruction stream,  event_pending
will only be set by the set in the paths altered by this patch, which is
the four whitelisted vectors.

> I think it would be better to run this check before the X86EMUL_UNHANDLEABLE 
> one
> and convert injections that we choose not to handle into
> X86EMUL_UNHANDLEABLE.
>
> Which I guess brings us back full circle to the behaviour we had
> before, and perhaps the right change to the earlier patch is to
> start down this road, with an explanatory comment.
>
> e.g. start with something like this, immediately after the first call
> to x86_emulate():
>
> /*
>  * Events raised within the emulator itself used to return
>  * X86EMUL_UNHANDLEABLE because we didn't supply injection
>  * callbacks.  Now the emulator supplies those to us via
>  * ctxt.event_pending instead.  Preserve the old behaviour
>  * for now.
>  */
>  if (emul_ctxt.ctxt.event_pending)
>  r = X86EMUL_UNHANDLEABLE;
>
> And in this patch, replace it with the hunk you have above, but
> setting r = X86EMUL_UNHANDLEABLE instead of injecting #GP.
>
> Does that make sense?

It does make sense, but that goes against the comment of not unshadowing
on exception.

A lot of this revolves around how likely we are to hit the #GP[0] case. 
I assert that we shouldn't be able to hit it unless the guest is playing
games, or we have a bug in emulation.

If we don't go throwing a #GP back, we should at least leave something
obvious in the log.

>
> Also, I'm a little confused after all this as to whether the emulator
> can still return with X86EMUL_OKAY and the event_pending set.

I have now determined this not to be the case.  Apologies for my
misinformation in v1.

All exception and software interrupt cases end up returning X86_EXCEPTION.

case 0xcd: /* int imm8 */
swint_type = x86_swint_int;
swint:
rc = inject_swint(swint_type, (uint8_t)src.val,
  _regs.eip - ctxt->regs->eip,
  ctxt, ops) ? : X86EMUL_EXCEPTION;
goto done;


This is why I introduced the slightly relaxed check:

if ( emul_ctxt.ctxt.event_pending )
ASSERT(r == X86EMUL_EXCEPTION);

in the earlier patch.

> If it
> can do that then we need to inject the event come what may, because
> any other side-effects will have been committted already. 

Because of the shadow pagetables use of x86_swint_emulate_none, all
software interrupts have fault semantics, so %eip isn't moved forward;
this is left to hardware on the re-inject path.  There are no other
pieces of state change for any software interrupts.

With some re-evaluation of hindsight, I plan to make all trap injection
have fault semantics out of x86_emulate(), leaving the possible
adjustment of %eip to the lower level vendor 

Re: [Xen-devel] [PATCH v3.1 12/15] xen/x86: populate PVHv2 Dom0 physical memory map

[Roger Pau Monne]

On Mon, Nov 28, 2016 at 06:49:42AM -0700, Jan Beulich wrote:
> >>> On 28.11.16 at 14:30,  wrote:
> > On Mon, Nov 28, 2016 at 04:41:22AM -0700, Jan Beulich wrote:
> >> >>> On 28.11.16 at 12:26,  wrote:
> >> > On Fri, Nov 11, 2016 at 10:16:43AM -0700, Jan Beulich wrote:
> >> >> >>> On 29.10.16 at 10:59,  wrote:
> >> >> > +saved_current = current;
> >> >> > +set_current(v);
> >> >> > +rc = hvm_copy_to_guest_phys(d->arch.e820[i].addr,
> >> >> > +
> >> >> > maddr_to_virt(d->arch.e820[i].addr),
> >> >> > +end - d->arch.e820[i].addr);
> >> >> > +set_current(saved_current);
> >> >> 
> >> >> If anything goes wrong here, how much confusion will result from
> >> >> current being wrong? In particular, will this complicate debugging
> >> >> of possible issues?
> >> > 
> >> > TBH, I'm not sure, current in this case is the idle domain, so trying to 
> >> > execute 
> >> > a hvm_copy_to_guest_phys with current being the idle domain, which from 
> >> > a Xen 
> >> > PoV is a PV vCPU, would probably result in some assert triggering in the 
> >> > hvm_copy_to_guest_phys path (or at least I would expect so). Note that 
> >> > this 
> > 
> >> > chunk of code is removed, since RAM regions below 1MB are now mapped as 
> >> > p2m_ram_rw.
> >> 
> >> Even if this chunk of code no longer exists, iirc there  were a few
> >> more instances of this current overriding, so unless they're all gone
> >> now I still think this need considering (and ideally finding a better
> >> solution, maybe along the lines of mapcache_override_current()).
> > 
> > This could be solved by making __hvm_copy take a struct domain param, but 
> > this 
> > is a very big change. I could also try to fix __hvm_copy so that we can set 
> > an 
> > override vcpu, much like mapcache_override_current (hvm_override_current?).
> 
> Well, as implied before: If there's provably no harm to debuggability,
> then perhaps there's no real need for you to change your code. If,
> however, there remains any doubt, then I specifically suggested
> that override variant, knowing that handing a proper struct vcpu *
> or struct domain * to the function would likely end up touching a lot
> of code.

Hm, I don't really see any harm ATM, but I'm also wondering whether I should 
add 
a helper that does all this, there are multiple instances of the 
set_current/hvm_copy/set_current construct throughout the series, so adding a 
hvm_copy_to_phys seems quite sensible.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

[Roger Pau Monné]

On Mon, Nov 28, 2016 at 10:16:33AM -0500, Boris Ostrovsky wrote:
> On 11/22/2016 09:08 AM, Jan Beulich wrote:
>  On 22.11.16 at 13:38,  wrote:
> >> On 11/22/2016 06:34 AM, Jan Beulich wrote:
> >> On 21.11.16 at 22:00,  wrote:
>  PVH guests will have ACPI accesses emulated by the hypervisor
>  as opposed to QEMU (as is the case for HVM guests)
> 
>  Support for IOREQ server emulation of CPU hotplug is indicated
>  by XEN_X86_EMU_IOREQ_CPUHP flag.
> 
>  Logic for the handler will be provided by a later patch.
> 
>  Signed-off-by: Boris Ostrovsky 
>  ---
>  CC: Paul Durrant 
>  ---
>  Changes in v3:
>  * acpi_ioaccess() returns X86EMUL_UNHANDLEABLE
>  * Renamed XEN_X86_EMU_IOREQ_CPUHP to XEN_X86_EMU_ACPI_FF (together
>    with corresponding has_*())
> >>> Except in the description above.
> >>>
> >>> Also, while I'm fine with the flag rename, has_acpi_ff() looks wrong
> >>> (or at least misleading) to me: Both HVM and PVHv2 have fixed
> >>> function hardware emulated, they only differ in who the emulator
> >>> is. Reduced hardware, if we would emulate such down the road,
> >>> otoh might then indeed come without. So how about one of
> >>> has_xen_acpi_ff() or has_dm_acpi_ff()?
> >> I think the latter is better. But then to keep flag names in sync with 
> >> has_*() macros, how about XEN_X86_EMU_DM_ACPI_FF?
> > Not sure - the flag name, as said, seemed fine to me before, and I
> > don't overly care about the two names fully matching up. Maybe
> > others here have an opinion?
> 
> Any preferences? Roger?

I don't really have a strong opinion, so far we have named all the macros after 
s/XEN_X86_EMU//, so if the macro is named has_dm_acpi_ff the mask should be 
XEN_X86_EMU_DM_ACPI_FF (but again this is more for coherence that anything 
else).

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v2 05/11] multiboot2: Add description of support for EFI boot services

[Daniel Kiper]

Hi Toomas,

Thank you for comments.

On Thu, Nov 24, 2016 at 11:47:48PM +0200, Toomas Soome wrote:
> There is still the same confusion as with entry address tag 7; the diagram has

I suppose that you thought about tag type 3.

> u_virt, yet the text does claim it is physical address. Sure, it is assumed 
> the
> identity mapping, but still those names are creating confusion.

If yes then I agree that u_virt should be changed to u_phys. Though maybe in
longterm we should define tags for every architecture separately with types
specific for a given architecture. Then we should avoid most of such confusions.
I hope...

> Moreover, the EFI32 and EFI64 have different address sizes (32 versus 64 bit),
> yet there is the same type: u_virt - so it hints the upper part of the 64bit
> address is ignored, but its not really clear from the text???

It is clear that it should be u_phys or u32 for EFI i386. Though I am not sure
about EFI amd64 right now. Potentially it could be u64. However, I assume (at
least right now; and current GRUB implementation works in that way) that the 
boot
loader cannot put any part of an image higher than 4 GiB - 1 (well, I agree that
it should be mentioned in spec). Even on EFI amd64 platform. This is because 
still
some of the image boot code can be executed in 32-bit mode. We have such 
situation
in Xen. So, from this point of view 32-bit entry_addr in tag type 9 is 
sufficient.
Though I can agree that we should anticipate support for full 64-bit images.
I think that it is possible (but not implemented yet). We should add to spec tag
which says: yes, I am 64-bit image. Then the image may provide relevant 64-bit
equivalent tags (defined properly in spec). So, in this case we should have in 
spec
another EFI amd64 tag which has 64-bit entry_addr. This way various boot code 
types
(32-bit and 64-bit) may coexist without any issue in one image and boot loader 
may
choose supported one. Does it make sense?

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko]

On 11/28/2016 05:00 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:56, Oleksandr Andrushchenko wrote:

On 11/28/2016 04:24 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:12, Oleksandr Andrushchenko wrote:


On 11/28/2016 03:27 PM, Jan Beulich wrote:

+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page
describing
+ *   page directory. Must be 0 if no more pages in the list.


If I am not mistaken 0 is a valid grant.


Then I will remove this sentence, anyways BE knows how many grefs there
are for the buffer size given

BTW, xen-blkfrint.c:
#define GRANT_INVALID_REF0
this is from where I got "Must be 0 if no more pages in the list."

+ * gref[i] - grant_ref_t, reference to a shared page of the buffer
+ *   allocated at XENSND_OP_OPEN
+ *
+ * Number of grant_ref_t entries in the whole page directory is not
+ * passed, but instead can be calculated as:
+ *   num_grefs_total = DIV_ROUND_UP(XENSND_OP_OPEN.buffer_sz,
PAGE_SIZE);

The header should be self contained, and there's no DIV_ROUND_UP()
anywhere under public/io/ for a reader to refer to. Please express 
this

using mathematical terms plus, if needed, standard C library ones.

done, will put:
num_grefs_total = (XENSND_OP_OPEN.buffer_sz + PAGE_SIZE - 1) / 
PAGE_SIZE


Can we avoid to use PAGE_SIZE in the header? Xen, the front-end and
the back-end may have different page size.

then, I believe, the protocol should implement something like blkif 
does?

Multi-page buffer which depends on front and back page sizes?
(blkif: max-ring-page-order/ring-ref%u/ring-page-order)
Is this what you mean?


It is not what I meant. I asked to define PAGE_SIZE. Is it the the 
PAGE_SIZE of Xen? PAGE_SIZE of the backend? PAGE_SIZE of the frontend?


Currently PV driver PAGE_SIZE is based on the size of a grant page.
As per my understanding, I can put XEN_PAGE_SIZE here, because 
xen/page.h says:

" * We assume that PAGE_SIZE is a multiple of XEN_PAGE_SIZE
 * XXX: Add a BUILD_BUG_ON?
"
meaning that PAGE_SIZE on either side cannot be less than XEN_PAGE_SIZE
Will XEN_PAGE_SIZE fit then?

Regards,




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Kernel Panics on Xen ARM64 for Domain0 and Guest

[t...@kernel.org]

Hello,

On Mon, Nov 28, 2016 at 11:59:15AM +, Julien Grall wrote:
> > commit 3ca45a46f8af8c4a92dd8a08eac57787242d5021
> > percpu: ensure the requested alignment is power of two
> 
> It would have been useful to specify the tree used. In this case,
> this commit comes from linux-next.

I'm surprised this actually triggered.

> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index f193414..4986dc0 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -372,8 +372,7 @@ static int __init xen_guest_init(void)
>  * for secondary CPUs as they are brought up.
>  * For uniformity we use VCPUOP_register_vcpu_info even on cpu0.
>  */
> -   xen_vcpu_info = __alloc_percpu(sizeof(struct vcpu_info),
> -  sizeof(struct vcpu_info));
> +   xen_vcpu_info = alloc_percpu(struct vcpu_info);
> if (xen_vcpu_info == NULL)
> return -ENOMEM;

Yes, this looks correct.  Can you please cc stable too?  percpu
allocator never supported alignments which aren't power of two and has
always behaved incorrectly with alignments which aren't power of two.

Thanks.

-- 
tejun

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.7-testing test] 102689: regressions - FAIL

[osstest service owner]

flight 102689 qemu-upstream-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102689/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 100711
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
100711
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 100711

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100711

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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuue27a2f17bc2d9d7f8afce2c5918f4f23937b268e
baseline version:
 qemuue927b5f5a809f07b73b063831527c8a87f053933

Last test of basis   100711  2016-09-02 02:46:43 Z   87 days
Testing same since   102532  2016-11-22 20:11:32 Z5 days9 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm  

Re: [Xen-devel] some thoughts about merlot{0|1} issues [was: Re: [xen-unstable test] 102522: tolerable FAIL - PUSHED]

[Konrad Rzeszutek Wilk]

On Mon, Nov 28, 2016 at 08:48:30AM -0500, Boris Ostrovsky wrote:
> On 11/24/2016 10:31 AM, Jan Beulich wrote:
>  On 24.11.16 at 16:14,  wrote:
> >> When dumping ACPI C states, here's how things look like for _all_ CPUs:
> >> Nov 23 13:13:00.382134 (XEN) ==cpu3==
> >> Nov 23 13:13:00.382157 (XEN) active state: C-1
> >> Nov 23 13:13:00.390096 (XEN) max_cstate:   C7
> >> Nov 23 13:13:00.390125 (XEN) states:
> >> Nov 23 13:13:00.390148 (XEN) C1:   type[C1] latency[000] 
> >> usage[] method[ HALT] duration[0]
> >> Nov 23 13:13:00.398055 (XEN) C0:   usage[] 
> >> duration[4229118701384]
> >> Nov 23 13:13:00.398090 (XEN) PC2[0] PC3[0] PC6[0] PC7[0]
> >> Nov 23 13:13:00.406088 (XEN) CC3[0] CC6[0] CC7[0]
> >>
> >> And I checked other runs, and it's the same everywhere.
> >>
> >> I remember that Jan suggested trying to pass max_cstate=1 to Xen at
> >> boot. I was about to ask Ian to do that for this host, but it looks
> >> like we're using only C0 and C1 already anyway.
> > This indeed looks surprising for a half way modern system - is the
> > BIOS perhaps limiting C-states (maybe instructed to via BIOS setup)?
> 
> 
> IIRC some BIOSes indeed provided an option to disable C2. Dumping SSDT
> would tell us whether C2 is there is BIOS is not accessible.

Keep in mind that not all C states are exposed if MWAIT is not exposed
to dom0 (see xen_check_mwait in arch/x86/xen/enlighten.c).

I recall some emails from Andrew about the CPU faulting and his CPUID
patches inhibiting this but it may very well be fixed?

Dario, lastly - did you have xen-acpi-processor loaded or built in your kernel?
> 
> -boris
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 07/11] pvh/ioreq: Install handlers for ACPI-related PVH IO accesses

[Boris Ostrovsky]

On 11/22/2016 09:08 AM, Jan Beulich wrote:
 On 22.11.16 at 13:38,  wrote:
>> On 11/22/2016 06:34 AM, Jan Beulich wrote:
>> On 21.11.16 at 22:00,  wrote:
 PVH guests will have ACPI accesses emulated by the hypervisor
 as opposed to QEMU (as is the case for HVM guests)

 Support for IOREQ server emulation of CPU hotplug is indicated
 by XEN_X86_EMU_IOREQ_CPUHP flag.

 Logic for the handler will be provided by a later patch.

 Signed-off-by: Boris Ostrovsky 
 ---
 CC: Paul Durrant 
 ---
 Changes in v3:
 * acpi_ioaccess() returns X86EMUL_UNHANDLEABLE
 * Renamed XEN_X86_EMU_IOREQ_CPUHP to XEN_X86_EMU_ACPI_FF (together
   with corresponding has_*())
>>> Except in the description above.
>>>
>>> Also, while I'm fine with the flag rename, has_acpi_ff() looks wrong
>>> (or at least misleading) to me: Both HVM and PVHv2 have fixed
>>> function hardware emulated, they only differ in who the emulator
>>> is. Reduced hardware, if we would emulate such down the road,
>>> otoh might then indeed come without. So how about one of
>>> has_xen_acpi_ff() or has_dm_acpi_ff()?
>> I think the latter is better. But then to keep flag names in sync with 
>> has_*() macros, how about XEN_X86_EMU_DM_ACPI_FF?
> Not sure - the flag name, as said, seemed fine to me before, and I
> don't overly care about the two names fully matching up. Maybe
> others here have an opinion?

Any preferences? Roger?

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [distros-debian-sid test] 68113: tolerable FAIL

[Platform Team regression test user]

flight 68113 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68113/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 68072
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 68072
 test-amd64-amd64-i386-sid-netboot-pygrub  9 debian-di-install  fail like 68072
 test-armhf-armhf-armhf-sid-netboot-pygrub  9 debian-di-install fail like 68072
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 68072

baseline version:
 flight   68072

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] arm64: Approach for DT based NUMA and issues

[Vijay Kilari]

On Mon, Nov 28, 2016 at 7:20 PM, Andre Przywara  wrote:
> Hi Vijay,
>
> On 26/11/16 06:59, Vijay Kilari wrote:
>> Hi,
>>
>>Below basic write up on DT based NUMA feature support for arm64 platform.
>> I have attempted to get NUMA support, However I face below issues. I would 
>> like
>> to discuss these issues. Please let me know your comments on this. Yet to 
>> look
>> at ACPI support.
>>
>> DT based NUMA support for arm64 platform
>> 
>> For Xen boot on NUMA arm64 platform, Xen needs to parse
>> CPU and Memory nodes for DT based booting mechanism. Here I would
>> like to discuss about DT based booting mechanism and the issues
>> related to it.
>>
>> 1) Parsing CPU and Memory nodes:
>> ---
>>
>> The numa information associated for CPU and Memory are passed in DT
>> using numa-node-id u32-interger value. More information about NUMA binding
>> is available in linux kernel @ Documentation/devicetree/bindings/numa.txt
>>
>> Similar to Linux kernel, cpu and memory nodes of DT are parsed
>> and numa-node-id information is populated in cpu_parsed and memory_parsed
>> node_t mask.
>>
>> When booting in UEFI mode, UEFI passes memory information to Dom0
>> using EFI memory descriptor table and deletes the memory nodes
>> from the host DT. However to fetch the memory numa node id, memory DT
>> node should not be deleted by EFI stub.
>
> So is this what the Cavium UEFI firmware actually does today?
> I have been told that removing the DT memory nodes was the original idea
> when UEFI was architected for ARM, but it's not clear whether this is
> actually implemented. Also this may differ from platform to platform, I
> guess.
> I don't have easy access to a box, so can't check atm.

Please see the patch from Ard in kernel. This change is required in
Xen EFI as well.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/firmware/efi/arm-init.c?id=500899c2cc3e3f06140373b587a69d30650f2d9d

>
>> ISSUE: When memory node is _NOT_ deleted by EFI stub from host DT,
>> Xen identifies the memory node [xen/arch/arm/bootfdt.c, early_scan_node() ]
>> which adds memory ranges to bootinfo.mem structure there by adding duplicate
>> entry and eventually initialization fails.
>>
>> Possible Solution: While adding new memory region to bootinfo.mem, check for
>> duplicate entries and back off if entry is already available from UEFI mem 
>> info
>> table.
>
> So why do we iterate over DT nodes if we have populated via the UEFI
> memmap already? Can't we just have an order:
> 1) if UEFI memmap available: parse that, populate bootinfo.mem, ignore DT
> 2) if UEFI not available, parse DT memory nodes, populate bootinfo.mem

Yes, could be done. will have a look
>
> So to make this work with NUMA, we would add another chain for NUMA parsing:
> 1) if ACPI is available, use the SRAT table
> 2) if ACPI is not available, check the DT memory nodes
>
> This should work with all cases: pure DT, UEFI with DT, UEFI with ACPI
>
>>
>> 2) Parsing CPU nodes:
>> -
>> The CPU nodes are parsed to extract numa-node-id info for each cpu and
>> cpu_nodemask is populated.
>>
>> The MPIDR register value is read for each CPU and cpu_to_node[] is populated.
>
> So there is no issue here and that works as expected?

No issue. Already MPIDR is read on secondary cpu boot from which cpu_to_node[]
data is updated

>
>> 3) Parsing Memory nodes:
>> --
>> For all the DT memory nodes in the flattend DT, start address, size
>> and numa-node-id value is extracted and stored in "node_memblk_range[]"
>> which is of type struct node.
>>
>> Each bootinfo.mem entry from UEFI is verified against node_memblk_range[] and
>> NODE_DATA is populated with start PFN, end PFN and nodeid.
>>
>> Populating memnodemap:
>>
>> The memnodemap[] is allocated from heap and using the NODE_DATA structure,
>> the memnodemap[] is populated with nodeid for each page index.
>>
>> This memnodemap info is used to fetch memory node id for a given page
>> by calling phys_to_nid() by memory allocator.
>>
>> ISSUE: phys_to_nid() is called by memory allocator before memnodemap[]
>> is initialized.
>>
>> Since memnodemap[] is allocated from heap, and hence boot allocator should
>> be initialized. The boot_allocator() needs phys_to_nid() which is not
>> available untill memnodemap[] is initialized. So there is deadlock situation
>> during initialization. To overcome this phsy_to_nid() should rely on
>> node_memblk_range[] to get nodeid untill memnodemap[] is initialized.
>
> What about having an early boot fallback: like:
>
> nodeid_t phys_to_nid(paddr_t addr)
> {
> if (!memnodemap)
> return 0;
> 
> }

The memory allocator has all the nodes memory from bootinfo.mem
So, memory allocator fails when phys_to_nid() returns 0 for node 1 memory.

>
> Cheers,
> Andre.
>
>> 4) 

Re: [Xen-devel] [ler...@redhat.com: Re: [PATCH v3] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier]

[Konrad Rzeszutek Wilk]

On Mon, Nov 28, 2016 at 12:38:08PM +, Anthony PERARD wrote:
> On Fri, Nov 25, 2016 at 08:24:00AM -0500, Konrad Rzeszutek Wilk wrote:
> > Hey Wei, Anthony,
> > 
> > Are you guys OK pushing this commit: 2667ad40919a in the
> > git://xenbits.xen.org/ovmf.git 
> > 
> > tree? Without this I cannot build Xen 4.8 with TianoCore
> > (--enable-ovmf).
> 
> Can you actually start a guest this OVMF (when it's build on Fedora Core
> 25, and built using the GCC5 toolchain)?

Hadn't gotten to that part yet.
> 
> On Arch Linux (gcc (GCC) 6.2.1 20160830), if I build OVMF with the GCC5
> toolchain, the firmware fail to boot.

Yikes!
> 
> For reference, I have this error:
>  X64 Exception Type - 06(#UD - Invalid Opcode)  CPU Apic ID -  
> 
> RIP  - 1F26AF6B, CS  - 0038, RFLAGS - 00010202
> RAX  - 0001, RCX - 1F26AF51, RDX - 0004
> RBX  - , RSP - 1F43C510, RBP - 1E583D18
> RSI  - 0003, RDI - 0001
> R8   - , R9  - , R10 - 1E58DB98
> R11  - 0002, R12 - 1E58D898, R13 - 
> R14  - 1E58D8A0, R15 - 1F26D001
> DS   - 0030, ES  - 0030, FS  - 0030
> GS   - 0030, SS  - 0030
> CR0  - 8033, CR2 - , CR3 - 1F3DB000
> CR4  - 0668, CR8 - 
> DR0  - , DR1 - , DR2 - 
> DR3  - , DR6 - 0FF0, DR7 - 0400
> GDTR - 1F3C9A98 0047, LDTR - 
> IDTR - 1EB0A018 0FFF,   TR - 
> FXSAVE_STATE - 1F43C170
>  Find PE image 
> ./Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/XenBusDxe/XenBusDxe/DEBUG/XenBusDxe.dll
>  (ImageBase=1F266000, EntryPoint=1F2669D5) 
> 
> I'll try to investigate, and report upstream.
> 
> -- 
> Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Julien Grall]

Hi Oleksandr,

On 28/11/16 14:56, Oleksandr Andrushchenko wrote:

On 11/28/2016 04:24 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:12, Oleksandr Andrushchenko wrote:


On 11/28/2016 03:27 PM, Jan Beulich wrote:

+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page
describing
+ *   page directory. Must be 0 if no more pages in the list.


If I am not mistaken 0 is a valid grant.


Then I will remove this sentence, anyways BE knows how many grefs there
are for the buffer size given

+ * gref[i] - grant_ref_t, reference to a shared page of the buffer
+ *   allocated at XENSND_OP_OPEN
+ *
+ * Number of grant_ref_t entries in the whole page directory is not
+ * passed, but instead can be calculated as:
+ *   num_grefs_total = DIV_ROUND_UP(XENSND_OP_OPEN.buffer_sz,
PAGE_SIZE);

The header should be self contained, and there's no DIV_ROUND_UP()
anywhere under public/io/ for a reader to refer to. Please express this
using mathematical terms plus, if needed, standard C library ones.

done, will put:
num_grefs_total = (XENSND_OP_OPEN.buffer_sz + PAGE_SIZE - 1) / PAGE_SIZE


Can we avoid to use PAGE_SIZE in the header? Xen, the front-end and
the back-end may have different page size.


then, I believe, the protocol should implement something like blkif does?
Multi-page buffer which depends on front and back page sizes?
(blkif: max-ring-page-order/ring-ref%u/ring-page-order)
Is this what you mean?


It is not what I meant. I asked to define PAGE_SIZE. Is it the the 
PAGE_SIZE of Xen? PAGE_SIZE of the backend? PAGE_SIZE of the frontend?


Currently PV driver PAGE_SIZE is based on the size of a grant page.

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko]

On 11/28/2016 04:24 PM, Julien Grall wrote:

Hi Oleksandr,

On 28/11/16 14:12, Oleksandr Andrushchenko wrote:


On 11/28/2016 03:27 PM, Jan Beulich wrote:

+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page
describing
+ *   page directory. Must be 0 if no more pages in the list.


If I am not mistaken 0 is a valid grant.


Then I will remove this sentence, anyways BE knows how many grefs there
are for the buffer size given

+ * gref[i] - grant_ref_t, reference to a shared page of the buffer
+ *   allocated at XENSND_OP_OPEN
+ *
+ * Number of grant_ref_t entries in the whole page directory is not
+ * passed, but instead can be calculated as:
+ *   num_grefs_total = DIV_ROUND_UP(XENSND_OP_OPEN.buffer_sz,
PAGE_SIZE);

The header should be self contained, and there's no DIV_ROUND_UP()
anywhere under public/io/ for a reader to refer to. Please express this
using mathematical terms plus, if needed, standard C library ones.

done, will put:
num_grefs_total = (XENSND_OP_OPEN.buffer_sz + PAGE_SIZE - 1) / PAGE_SIZE


Can we avoid to use PAGE_SIZE in the header? Xen, the front-end and 
the back-end may have different page size.



then, I believe, the protocol should implement something like blkif does?
Multi-page buffer which depends on front and back page sizes?
(blkif: max-ring-page-order/ring-ref%u/ring-page-order)
Is this what you mean?


Regards,




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 17/19] x86/hvm: Avoid __hvm_copy() raising #PF behind the emulators back

[Tim Deegan]

At 11:13 + on 28 Nov (1480331614), Andrew Cooper wrote:
> Drop the call to hvm_inject_page_fault() in __hvm_copy(), and require callers
> to inject the pagefault themselves.

This seems like it'd be easy to forget to DTRT with the fault,
especially in code being ported forward across this series.

Would it be better to have hvm_copy  take a callback function
instead of a pfinfo pointer?

(In any case, this can have my ack for the shadow-code change.)

Cheers,

Tim.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 13/19] x86/shadow: Avoid raising faults behind the emulators back

[Tim Deegan]

Hi,

At 11:13 + on 28 Nov (1480331610), Andrew Cooper wrote:
> Use x86_emul_{hw_exception,pagefault}() rather than
> {pv,hvm}_inject_page_fault() and hvm_inject_hw_exception() to cause raised
> faults to be known to the emulator.  This requires altering the callers of
> x86_emulate() to properly re-inject the event.
> 
> While fixing this, fix the singlestep behaviour.  Previously, an otherwise
> successful emulation would fail if singlestepping was active, as the emulator
> couldn't raise #DB.  This is unreasonable from the point of view of the guest.
> 
> We therefore tolerate #PF/#GP/SS and #DB being raised by the emulator, but
> reject anything else as unexpected.
> 
> Signed-off-by: Andrew Cooper 

> +if ( r == X86EMUL_EXCEPTION && emul_ctxt.ctxt.event_pending )
> +{
> +/*
> + * This emulation covers writes to shadow pagetables.  We tolerate 
> #PF
> + * (from hitting adjacent pages), #GP/#SS (from segmentation errors),
> + * and #DB (from singlestepping).  Anything else is an emulation bug,
> + * or a guest playing with the instruction stream under Xen's feet.
> + */
> +if ( emul_ctxt.ctxt.event.type == X86_EVENTTYPE_HW_EXCEPTION &&
> + (emul_ctxt.ctxt.event.vector < 32) &&
> + ((1u << emul_ctxt.ctxt.event.vector) &
> +  ((1u << TRAP_debug) | (1u << TRAP_stack_error) |
> +   (1u << TRAP_gp_fault) | (1u << TRAP_page_fault))) )
> +{
> +if ( is_hvm_vcpu(v) )
> +hvm_inject_event(_ctxt.ctxt.event);
> +else
> +pv_inject_event(_ctxt.ctxt.event);
> +}
> +else
> +{
> +if ( is_hvm_vcpu(v) )
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +else
> +pv_inject_hw_exception(TRAP_gp_fault, 0);
> +}

I don't think it's OK to lob #GP into a HVM guest here -- we can hit
this path even if the guest isn't behaving strangely.  I think it
would be better to run this check before the X86EMUL_UNHANDLEABLE one
and convert injections that we choose not to handle into
X86EMUL_UNHANDLEABLE.

Which I guess brings us back full circle to the behaviour we had
before, and perhaps the right change to the earlier patch is to
start down this road, with an explanatory comment.

e.g. start with something like this, immediately after the first call
to x86_emulate():

/*
 * Events raised within the emulator itself used to return
 * X86EMUL_UNHANDLEABLE because we didn't supply injection
 * callbacks.  Now the emulator supplies those to us via
 * ctxt.event_pending instead.  Preserve the old behaviour
 * for now.
 */
 if (emul_ctxt.ctxt.event_pending)
 r = X86EMUL_UNHANDLEABLE;

And in this patch, replace it with the hunk you have above, but
setting r = X86EMUL_UNHANDLEABLE instead of injecting #GP.

Does that make sense?

Also, I'm a little confused after all this as to whether the emulator
can still return with X86EMUL_OKAY and the event_pending set.  If it
can do that then we need to inject the event come what may, because
any other side-effects will have been committted already. 

> @@ -3475,6 +3503,37 @@ static int sh_page_fault(struct vcpu *v,
>  {
>  perfc_incr(shadow_em_ex_fail);
>  TRACE_SHADOW_PATH_FLAG(TRCE_SFLAG_EMULATION_LAST_FAILED);
> +
> +if ( r == X86EMUL_EXCEPTION && emul_ctxt.ctxt.event_pending )
> +{
> +/*
> + * This emulation covers writes to shadow pagetables.  We
> + * tolerate #PF (from hitting adjacent pages), #GP/#SS
> + * (from segmentation errors), and #DB (from
> + * singlestepping).  Anything else is an emulation bug, 
> or
> + * a guest playing with the instruction stream under 
> Xen's
> + * feet.
> + */
> +if ( emul_ctxt.ctxt.event.type == 
> X86_EVENTTYPE_HW_EXCEPTION &&
> + (emul_ctxt.ctxt.event.vector < 32) &&
> + ((1u << emul_ctxt.ctxt.event.vector) &
> +  ((1u << TRAP_debug) | (1u << TRAP_stack_error) |
> +   (1u << TRAP_gp_fault) | (1u << TRAP_page_fault))) 
> )
> +{
> +if ( is_hvm_vcpu(v) )
> +hvm_inject_event(_ctxt.ctxt.event);
> +else
> +pv_inject_event(_ctxt.ctxt.event);
> +}
> +else
> +{
> +if ( is_hvm_vcpu(v) )
> +hvm_inject_hw_exception(TRAP_gp_fault, 0);
> +else
> +pv_inject_hw_exception(TRAP_gp_fault, 0);
> +}
> + 

Re: [Xen-devel] [PATCH v2 08/19] x86/emul: Rework emulator event injection

[Andrew Cooper]

On 28/11/16 14:24, Tim Deegan wrote:
> At 12:48 + on 28 Nov (1480337304), Andrew Cooper wrote:
>> On 28/11/16 12:04, Tim Deegan wrote:
>>> At 11:13 + on 28 Nov (1480331605), Andrew Cooper wrote:
 +/*
   * NB. We do not unshadow on X86EMUL_EXCEPTION. It's not clear that it
   * would be a good unshadow hint. If we *do* decide to 
 unshadow-on-fault
   * then it must be 'failable': we cannot require the unshadow to 
 succeed.
   */
 -if ( r == X86EMUL_UNHANDLEABLE )
 +if ( r == X86EMUL_UNHANDLEABLE || emul_ctxt.ctxt.event_pending )
>>> No thank you.  The comment there explains why we don't want to
>>> unshadow for an injection; please let it stand.  Or if the new
>>> semantics have changed, update the comment.
>> This addition is no functional behavioural change from before, which is
>> the point I was trying to get across.
> I can understand why you want to do it that way but it makes the
> series (and this code!) read quite oddly.  If you keep this, then
> please add a second comment above this line that explains why the code
> temporarily disagrees with the first comment. :)  You can delete that
> comment again in patch #13.
>
> With that, Acked-by: Tim Deegan 

How about this?

~Andrew

--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3374,11 +3374,33 @@ static int sh_page_fault(struct vcpu *v,
 r = x86_emulate(_ctxt.ctxt, emul_ops);
 
 /*
+ * TODO: Make this true:
+ *
+ASSERT(emul_ctxt.ctxt.event_pending == (rc == X86EMUL_EXCEPTION));
+ *
+ * Some codepaths still raise exceptions behind the back of the
+ * emulator. (i.e. return X86EMUL_EXCEPTION but without event_pending
+ * being set).  In the meantime, use a slightly relaxed check...
+ */
+if ( emul_ctxt.ctxt.event_pending )
+ASSERT(r == X86EMUL_EXCEPTION);
+
+/*
  * NB. We do not unshadow on X86EMUL_EXCEPTION. It's not clear that it
  * would be a good unshadow hint. If we *do* decide to
unshadow-on-fault
  * then it must be 'failable': we cannot require the unshadow to
succeed.
+ *
+ * Note: Despite the above comment, this path has actually been handing
+ * exception circumstances raised by the emulator itself (e.g.
singlestep)
+ * because of the lack of the inject_hw_exception() hook.
+ *
+ * With this change, exceptions raised behind the back of the emulator
+ * still return without setting event_pending, but exceptions raised by
+ * the emulator do.  Force these exceptions back onto the UNHANDLEABLE
+ * path for now, so they are similarly ignored.  A future change
will fix
+ * this properly.
  */
-if ( r == X86EMUL_UNHANDLEABLE )
+if ( r == X86EMUL_UNHANDLEABLE || emul_ctxt.ctxt.event_pending )
 {
 perfc_incr(shadow_fault_emulate_failed);



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Julien Grall]

Hi Oleksandr,

On 28/11/16 14:12, Oleksandr Andrushchenko wrote:


On 11/28/2016 03:27 PM, Jan Beulich wrote:

+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page
describing
+ *   page directory. Must be 0 if no more pages in the list.


If I am not mistaken 0 is a valid grant.


+ * gref[i] - grant_ref_t, reference to a shared page of the buffer
+ *   allocated at XENSND_OP_OPEN
+ *
+ * Number of grant_ref_t entries in the whole page directory is not
+ * passed, but instead can be calculated as:
+ *   num_grefs_total = DIV_ROUND_UP(XENSND_OP_OPEN.buffer_sz,
PAGE_SIZE);

The header should be self contained, and there's no DIV_ROUND_UP()
anywhere under public/io/ for a reader to refer to. Please express this
using mathematical terms plus, if needed, standard C library ones.

done, will put:
num_grefs_total = (XENSND_OP_OPEN.buffer_sz + PAGE_SIZE - 1) / PAGE_SIZE


Can we avoid to use PAGE_SIZE in the header? Xen, the front-end and the 
back-end may have different page size.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 08/19] x86/emul: Rework emulator event injection

[Tim Deegan]

At 12:48 + on 28 Nov (1480337304), Andrew Cooper wrote:
> On 28/11/16 12:04, Tim Deegan wrote:
> > At 11:13 + on 28 Nov (1480331605), Andrew Cooper wrote:
> >> +/*
> >>   * NB. We do not unshadow on X86EMUL_EXCEPTION. It's not clear that it
> >>   * would be a good unshadow hint. If we *do* decide to 
> >> unshadow-on-fault
> >>   * then it must be 'failable': we cannot require the unshadow to 
> >> succeed.
> >>   */
> >> -if ( r == X86EMUL_UNHANDLEABLE )
> >> +if ( r == X86EMUL_UNHANDLEABLE || emul_ctxt.ctxt.event_pending )
> > No thank you.  The comment there explains why we don't want to
> > unshadow for an injection; please let it stand.  Or if the new
> > semantics have changed, update the comment.
> 
> This addition is no functional behavioural change from before, which is
> the point I was trying to get across.

I can understand why you want to do it that way but it makes the
series (and this code!) read quite oddly.  If you keep this, then
please add a second comment above this line that explains why the code
temporarily disagrees with the first comment. :)  You can delete that
comment again in patch #13.

With that, Acked-by: Tim Deegan 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 for-4.8] tools/libacpi: Fix compilation when cross building the tools

[Wei Liu]

On Mon, Nov 28, 2016 at 06:30:58AM -0700, Jan Beulich wrote:
> >>> On 28.11.16 at 14:13,  wrote:
> > The tools (such as mk_dsdt) can be cross-built when it may not be
> > desirable to build them on the target.
> > 
> > The commit c4ac1077 "libxl/arm: Generate static ACPI DSDT table"
> > introduced support of ARM64 in mk_dsdt but also break cross-building
> > tools because the ACPI tables are not correct.
> > 
> > While mk_dsdt should generate ACPI table for the target architecture, it
> > currently generates the one for the host. This is because the source
> > code contains reference to the host architecture (__aarch64__,
> > __x86_64__, __i386__) when it should be the target architecture.
> > 
> > Replace all __aarch64__, __x86_64__, __i386__ by the corresponding
> > CONFIG_*.
> > 
> > Also expose the CONFIG_* to the source code as the currently only
> > exposed to the Makefile.
> > 
> > Reported-by: Andrii Anisov 
> > Suggested-by: Wei Liu 
> > Signed-off-by: Julien Grall 
> > Reviewed-by: Andrew Cooper 
> 
> Reviewed-by: Jan Beulich 
> 

Release-acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 10/19] x86/hvm: Reposition the modification of raw segment data from the VMCB/VMCS

[Boris Ostrovsky]

On 11/28/2016 06:13 AM, Andrew Cooper wrote:
> Intel VT-x and AMD SVM provide access to the full segment descriptor cache via
> fields in the VMCB/VMCS.  However, the bits which are actually checked by
> hardware and preserved across vmentry/exit are inconsistent, and the vendor
> accessor functions perform inconsistent modification to the raw values.
>
> Convert {svm,vmx}_{get,set}_segment_register() into raw accessors, and alter
> hvm_{get,set}_segment_register() to cook the values consistently.  This allows
> the common emulation code to better rely on finding architecturally-expected
> values.
>
> While moving the code performing the cooking, fix the %ss.db quirk.  A NULL
> selector is indicated by .p being clear, not the value of the .type field.
>
> This does cause some functional changes because of the modifications being
> applied uniformly.  A side effect of this fixes latent bugs where
> vmx_set_segment_register() didn't correctly fix up .G for segments, and
> inconsistent fixing up of the GDTR/IDTR limits.
>
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Kevin Tian 
> Reviewed-by: Jan Beulich 

Reviewed-by: Boris Ostrovsky 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 68112: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68112 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68112/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 418373a1cd97abc0c0e3557f7a00105291829e6f
baseline version:
 ovmf f17e28c7911f6d2f985e7bb77e1c68cfd79bf056

Last test of basis68110  2016-11-28 03:21:17 Z0 days
Testing same since68112  2016-11-28 07:25:07 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 418373a1cd97abc0c0e3557f7a00105291829e6f
Author: Jiaxin Wu 
Date:   Fri Nov 25 14:14:23 2016 +0800

MdeModulePkg/NetLib: Handle an invalid IPv6 address case

Handle an invalid IPv6 address in NetLibAsciiStrToIp6(),
like '2000:::1com'.

Cc: Zhang Lubo 
Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
Reviewed-by: Fu Siyuan 
Reviewed-by: Zhang Lubo 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v13] This is the ABI for the two halves of a para-virtualized sound driver to communicate with each to other.

[Oleksandr Andrushchenko]

On 11/28/2016 03:27 PM, Jan Beulich wrote:

On 28.11.16 at 13:30,  wrote:

+ * Request open - open a PCM stream for playback or capture:
+ *  0 1  23
octet
+ * +-+-+-+-+
+ * | id| XENSND_OP_OPEN  | stream_idx  |
+ * +-+-+-+-+
+ * |padding|

This still say "padding" instead of "reserved". Also isn't this still part
of the common header?

done

+ * +-+-+-+-+
+ * |pcm_rate   |
+ * +-+-+-+-+
+ * |  pcm_format |  pcm_channels   | reserved  |
+ * +-+-+-+-+
+ * |   buffer_sz   |
+ * +-+-+-+-+
+ * | gref_directory_start  |
+ * +-+-+-+-+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|

Don't you elsewhere use this as an "and so one" marker? That's not
what you want here afaict, because of ...


+ * +-+-+-+-+
+ * |   reserved|
+ * +-+-+-+-+

... this.

done

+/*
+ * Shared page for XENSND_OP_OPEN buffer descriptor (gref_directory in the
+ *   request) employs a list of pages, describing all pages of the shared data
+ *   buffer:
+ *  0 1  23
octet
+ * +-+-+-+-+
+ * |  gref_dir_next_page   |
+ * +-+-+-+-+
+ * |gref[0]|
+ * +-+-+-+-+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +-+-+-+-+
+ * |gref[i]|
+ * +-+-+-+-+
+ * |/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +-+-+-+-+
+ * |gref[N -1] |
+ * +-+-+-+-+
+ *
+ * gref_dir_next_page - grant_ref_t, reference to the next page describing
+ *   page directory. Must be 0 if no more pages in the list.
+ * gref[i] - grant_ref_t, reference to a shared page of the buffer
+ *   allocated at XENSND_OP_OPEN
+ *
+ * Number of grant_ref_t entries in the whole page directory is not
+ * passed, but instead can be calculated as:
+ *   num_grefs_total = DIV_ROUND_UP(XENSND_OP_OPEN.buffer_sz, PAGE_SIZE);

The header should be self contained, and there's no DIV_ROUND_UP()
anywhere under public/io/ for a reader to refer to. Please express this
using mathematical terms plus, if needed, standard C library ones.

done, will put:
num_grefs_total = (XENSND_OP_OPEN.buffer_sz + PAGE_SIZE - 1) / PAGE_SIZE

+ * operation - XENSND_OP_MUTE for mute or XENSND_OP_UNMUTE for unmute
+ * Buffer passed with XENSND_OP_OPEN is used to exchange mute/unmute
+ * values:
+ *
+ *  0 1  23
octet
+ * +-+-+-+-+
+ * |   channel[0]|   channel[1]|   channel[2]|   channel[3]|
+ * +-+-+-+-+
+ * +/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +-+-+-+-+
+ * |   channel[i]|   channel[i+1]  |   channel[i+2]  |   channel[i+3]  |
+ * +-+-+-+-+
+ * +/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/|
+ * +-+-+-+-+

Iirc you had confirmed to change this, but you didn't: I can only repeat
that other than e.g. for the volume operations, it is unclear what the
upper bound here is, as you don't use N.

done

+struct xensnd_req {
+uint16_t id;
+uint8_t 

[Xen-devel] [PATCH] libxl: invert xc and domain model resume calls in xc_domain_resume()

[Cédric Bosdonnat]

Resume is sometimes silently failing for HVM guests. Getting the
xc_domain_resume() and libxl__domain_resume_device_model() in the
reverse order than what is in the suspend code fixes the problem.

Signed-off-by: Cédric Bosdonnat 
---
 tools/libxl/libxl_dom_suspend.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 0648919..3e29c01 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -456,12 +456,6 @@ int libxl__domain_resume(libxl__gc *gc, uint32_t domid, 
int suspend_cancel)
 {
 int rc = 0;
 
-if (xc_domain_resume(CTX->xch, domid, suspend_cancel)) {
-LOGE(ERROR, "xc_domain_resume failed for domain %u", domid);
-rc = ERROR_FAIL;
-goto out;
-}
-
 libxl_domain_type type = libxl__domain_type(gc, domid);
 if (type == LIBXL_DOMAIN_TYPE_INVALID) {
 rc = ERROR_FAIL;
@@ -477,6 +471,12 @@ int libxl__domain_resume(libxl__gc *gc, uint32_t domid, 
int suspend_cancel)
 }
 }
 
+if (xc_domain_resume(CTX->xch, domid, suspend_cancel)) {
+LOGE(ERROR, "xc_domain_resume failed for domain %u", domid);
+rc = ERROR_FAIL;
+goto out;
+}
+
 if (!xs_resume_domain(CTX->xsh, domid)) {
 LOGE(ERROR, "xs_resume_domain failed for domain %u", domid);
 rc = ERROR_FAIL;
-- 
2.10.2


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] arm64: Approach for DT based NUMA and issues

[Andre Przywara]

Hi Vijay,

On 26/11/16 06:59, Vijay Kilari wrote:
> Hi,
> 
>Below basic write up on DT based NUMA feature support for arm64 platform.
> I have attempted to get NUMA support, However I face below issues. I would 
> like
> to discuss these issues. Please let me know your comments on this. Yet to look
> at ACPI support.
> 
> DT based NUMA support for arm64 platform
> 
> For Xen boot on NUMA arm64 platform, Xen needs to parse
> CPU and Memory nodes for DT based booting mechanism. Here I would
> like to discuss about DT based booting mechanism and the issues
> related to it.
> 
> 1) Parsing CPU and Memory nodes:
> ---
> 
> The numa information associated for CPU and Memory are passed in DT
> using numa-node-id u32-interger value. More information about NUMA binding
> is available in linux kernel @ Documentation/devicetree/bindings/numa.txt
> 
> Similar to Linux kernel, cpu and memory nodes of DT are parsed
> and numa-node-id information is populated in cpu_parsed and memory_parsed
> node_t mask.
> 
> When booting in UEFI mode, UEFI passes memory information to Dom0
> using EFI memory descriptor table and deletes the memory nodes
> from the host DT. However to fetch the memory numa node id, memory DT
> node should not be deleted by EFI stub.

So is this what the Cavium UEFI firmware actually does today?
I have been told that removing the DT memory nodes was the original idea
when UEFI was architected for ARM, but it's not clear whether this is
actually implemented. Also this may differ from platform to platform, I
guess.
I don't have easy access to a box, so can't check atm.

> ISSUE: When memory node is _NOT_ deleted by EFI stub from host DT,
> Xen identifies the memory node [xen/arch/arm/bootfdt.c, early_scan_node() ]
> which adds memory ranges to bootinfo.mem structure there by adding duplicate
> entry and eventually initialization fails.
> 
> Possible Solution: While adding new memory region to bootinfo.mem, check for
> duplicate entries and back off if entry is already available from UEFI mem 
> info
> table.

So why do we iterate over DT nodes if we have populated via the UEFI
memmap already? Can't we just have an order:
1) if UEFI memmap available: parse that, populate bootinfo.mem, ignore DT
2) if UEFI not available, parse DT memory nodes, populate bootinfo.mem

So to make this work with NUMA, we would add another chain for NUMA parsing:
1) if ACPI is available, use the SRAT table
2) if ACPI is not available, check the DT memory nodes

This should work with all cases: pure DT, UEFI with DT, UEFI with ACPI

> 
> 2) Parsing CPU nodes:
> -
> The CPU nodes are parsed to extract numa-node-id info for each cpu and
> cpu_nodemask is populated.
> 
> The MPIDR register value is read for each CPU and cpu_to_node[] is populated.

So there is no issue here and that works as expected?

> 3) Parsing Memory nodes:
> --
> For all the DT memory nodes in the flattend DT, start address, size
> and numa-node-id value is extracted and stored in "node_memblk_range[]"
> which is of type struct node.
> 
> Each bootinfo.mem entry from UEFI is verified against node_memblk_range[] and
> NODE_DATA is populated with start PFN, end PFN and nodeid.
> 
> Populating memnodemap:
> 
> The memnodemap[] is allocated from heap and using the NODE_DATA structure,
> the memnodemap[] is populated with nodeid for each page index.
> 
> This memnodemap info is used to fetch memory node id for a given page
> by calling phys_to_nid() by memory allocator.
> 
> ISSUE: phys_to_nid() is called by memory allocator before memnodemap[]
> is initialized.
> 
> Since memnodemap[] is allocated from heap, and hence boot allocator should
> be initialized. The boot_allocator() needs phys_to_nid() which is not
> available untill memnodemap[] is initialized. So there is deadlock situation
> during initialization. To overcome this phsy_to_nid() should rely on
> node_memblk_range[] to get nodeid untill memnodemap[] is initialized.

What about having an early boot fallback: like:

nodeid_t phys_to_nid(paddr_t addr)
{
if (!memnodemap)
return 0;

}

Cheers,
Andre.

> 4) Generating memory nodes for DOM0
> -
> Linux kernel device drivers that uses devm_zalloc(), tries to allocate memory
> from local memory node. So Dom0 needs to have memory allocated on all the
> available nodes of the system.
> 
> Ex: SMMU driver of device on node 1 tries to allocate memory
> on node 1.
> 
> ISSUE:
>  - Dom0's memory should be split across all the available memory nodes
>of the system and memory nodes should be generated accordingly.
>  - Memory DT node generated by Xen for Dom0 should populate numa-node-id
>information.
> 
> Regards
> Vijay
> 

___
Xen-devel mailing list