[Xen-devel] [seabios test] 120351: regressions - FAIL

[osstest service owner]

flight 120351 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120351/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  5adc8bdea6a77bdb457d9cbca9a49a7d01cc25cd
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  126 days
Failing since115733  2017-11-10 17:19:59 Z  119 days  144 attempts
Testing same since   120197  2018-03-03 11:37:53 Z6 days4 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marc-André Lureau 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Nikolay Nikolov 
  Paul Menzel 
  Stefan Berger 
  Stephen Douthit 

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-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-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.

(No revision log; it would be 336 lines long.)

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

[Xen-devel] [rumprun test] 120360: regressions - FAIL

[osstest service owner]

flight 120360 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120360/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumprun6 rumprun-buildfail REGR. vs. 106754
 build-amd64-rumprun   6 rumprun-buildfail REGR. vs. 106754

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a

version targeted for testing:
 rumprun  94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c
baseline version:
 rumprun  c7f2f016becc1cd0e85da6e1b25a8e7f9fb2aa74

Last test of basis   106754  2017-03-18 04:21:25 Z  356 days
Testing same since   120360  2018-03-09 04:19:20 Z0 days1 attempts


People who touched revisions under test:
  Kent McLeod 
  Kent McLeod 
  Naja Melan 
  Sebastian Wicki 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-rumprun-amd64   blocked 
 test-amd64-i386-rumprun-i386 blocked 



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

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

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

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


Not pushing.


commit 94bdf32ac57b84c1b42150d21f0ad79b3b5dd99c
Merge: 8fe40c8 b3c1033
Author: Kent McLeod 
Date:   Fri Feb 16 09:15:45 2018 +1100

Merge pull request #118 from kent-mcleod/stretch-linking-defaultpie

Fix linking on Debian Stretch (gcc-6)

commit b3c1033b090b65e8e86999ddd063c174502aa3f0
Author: Kent McLeod 
Date:   Wed Feb 14 16:43:16 2018 +1100

Add further -no-pie checks to Rumprun build tools

This builds upon the previous commit to add -no-pie anywhere the
relocatable flag (-Wl,-r) is used to handle compilers that enable -pie
by default (Such as Debian Stretch).

commit 8fe40c84edddfbf472b4a7cce960df749701174c
Merge: c7f2f01 685f4ab
Author: Sebastian Wicki 
Date:   Fri Jan 5 15:04:18 2018 +0100

Merge pull request #112 from najamelan/bugfix/gcc7-fallthrough

Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7

commit 685f4ab3b74b6f1e1b40bdd3d2c42efa44bf385d
Author: Naja Melan 
Date:   Thu Jan 4 16:07:46 2018 +

Make the disabling of the fallthrough warning dependent on GCC version

This should prevent older gcc versions from choking on unknown argument.

I have not tested this, just wrote the code directly on github. Use with 
caution.

commit 34056451174e8722b972229fefc1bf9e0b89a7da
Author: Naja Melan 
Date:   Wed Jan 3 18:57:50 2018 +

Add the -Wimplicit-fallthrough=0 flag to allow compiling with GCC7

GCC7 comes with a new warning "implicit-fallthrough" which will prevent 
building the netbsd-src.

For more information: 
https://dzone.com/articles/implicit-fallthrough-in-gcc-7

commit 35d81194b7feb75d20af3ba4fdb45ea76230852f
Author: Wei Liu 
Date:   Wed Jun 7 16:30:00 2017 +0100

Fix linking on Debian Stretch

Provide cc-option. Use that to check if -no-pie is available and
append it when necessary.

Signed-off-by: Wei Liu 

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

[Xen-devel] [xen-4.9-testing test] 120336: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm   6 xen-install  fail REGR. vs. 12
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 12
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
12
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install  fail REGR. vs. 12
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 12

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 12

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 12
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 119954
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 119954
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 12
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 12
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  6b1a2704e7135d0781c4719616f6dac4a7bb904b
baseline version:
 xen  88fbabc49158b0b858248fa124ef590c5df7782f

Last test of basis   12  2018-02-24 21:12:43 Z   13 days
Failing since120063  2018-02-27 13:55:23 Z   10 days6 attempts
Testing same since   120336  2018-03-08 05:47:45 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel Sabogal 
  George Dunlap 
  Haozhong Zhang 
  Igor Druzhinin 
  Jan Beulich 
  Julien Grall 
  Ross Lagerwall 
  Stefano Stabellini 
  Wei Liu 

Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support

[Stefano Stabellini]

On Fri, 9 Mar 2018, Julien Grall wrote:
> Furthermore, the workaround is not in Linux upstream and I doubt this will be
> accepted as it is. So I am not convinced that we should modify Xen interface
> for that.
> 
> Anyway, given that your silicon is going to be respined, then you probably
> want to restrict to run on the same cluster.

Hi Pen,

I think that i.MX8 is a critical platform for the future of embedded
virtualization and I really want to support it in Xen out of the box.

However, I agree with Julien that if there will be a new version of the
silicon with this issue properly fixed in hardware, then it might not
make sense to add workarounds in Xen for this. Unless you think the
version of the hardware with the errata will be commercialized?

Do you plan to upstream your workaround in Linux? If not, then it might
be best for you to carry the workaround for Xen in your Xen tree, the
same way you'll do for Linux. For workarounds that affect/involve both
Linux and Xen, we tend to follow the same policy as the Linux kernel,
unless we have good reasons not to. On the other end, if you intend to
upstream the Linux workaround, then we can discuss what to do for Xen.


Also let me expand on one of Julien's suggestions that actually I think
is quite good. Assuming that we have the tlb maintenance workaround in
the hypervisor, it would be safe to start guests only in the big or only
in the little cluster, right? In other words, you could still use both
clusters but only starting guests in one or the other, not both. This is
a good compromise because it allows full usage of the hardware, a
relatively small patch in Xen, and no guest visible changes (such as
toolstack changes to modify the compatible line). Guest visible and user
visible changes are particularly troublesome to maintain in the long
term and this is reason why we are reticent in introducing them. The tlb
maintenance workaround in the hypervisor is something much easier to
manage and we could consider taking it in if hardware with the errata
will become available to customers.

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

[Michael Young]

On Fri, 9 Mar 2018, Christian Lindig wrote:





On 9. Mar 2018, at 22:57, Michael Young  wrote:

I have had a go at fixing the patch and my revised attempt is attached. I 
suspect it could be tidied up, but it works for me.


Thank you for giving this another go. What is the key difference to the 
previous patch which compiled but lead to lock up at run time? I briefly tried 
your patch and can confirm that it compiles and looks clean except for two 
trailing spaces.

— Christian

Acked-by: Christian Lindig 


The problem with the old patch is illustrated by the following section 
from the old patch for tools/ocaml/xenstored/utils.ml

@@ -85,7 +85,7 @@ let create_unix_socket name =
 let read_file_single_integer filename =
let fd = Unix.openfile filename [ Unix.O_RDONLY ] 0o640 in
let buf = String.make 20 (char_of_int 0) in
-   let sz = Unix.read fd buf 0 20 in
+   let sz = Unix.read fd (Bytes.of_string buf) 0 20 in
Unix.close fd;
int_of_string (String.sub buf 0 sz)

where the patch makes Unix.read write to a Bytes copy of buf and buf 
itself is unchanged, so int_of_string sees a string of null characters 
rather than a string to convert into a number. The net result is that 
information being read by oxenstored from the hypervisor is corrupted or 
lost.
The same basic problem also occurred in a couple of places in 
the old patch of tools/ocaml/libs/xb/xb.ml.
My fix for this is to switch to Bytes at an earlier stage, so for example 
the corresponding section in the new patch becomes

@@ -84,10 +84,10 @@ let create_unix_socket name =

 let read_file_single_integer filename =
let fd = Unix.openfile filename [ Unix.O_RDONLY ] 0o640 in
-   let buf = String.make 20 (char_of_int 0) in
+   let buf = Bytes.make 20 (char_of_int 0) in
let sz = Unix.read fd buf 0 20 in
Unix.close fd;
-   int_of_string (String.sub buf 0 sz)
+   int_of_string (Bytes.to_string (Bytes.sub buf 0 sz))

 let path_complete path connection_path =
if String.get path 0 <> '/' then

Michael Young___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 4.9 15/65] x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Juergen Gross 

commit 71c208dd54ab971036d83ff6d9837bae4976e623 upstream.

Older Xen versions (4.5 and before) might have problems migrating pv
guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before
suspending zero that MSR and restore it after being resumed.

Signed-off-by: Juergen Gross 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Jan Beulich 
Cc: sta...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20180226140818.4849-1-jgr...@suse.com
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/xen/suspend.c |   16 
 1 file changed, 16 insertions(+)

--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -1,11 +1,14 @@
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -68,6 +71,8 @@ static void xen_pv_post_suspend(int susp
xen_mm_unpin_all();
 }
 
+static DEFINE_PER_CPU(u64, spec_ctrl);
+
 void xen_arch_pre_suspend(void)
 {
if (xen_pv_domain())
@@ -84,6 +89,9 @@ void xen_arch_post_suspend(int cancelled
 
 static void xen_vcpu_notify_restore(void *data)
 {
+   if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
+   wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
+
/* Boot processor notified via generic timekeeping_resume() */
if (smp_processor_id() == 0)
return;
@@ -93,7 +101,15 @@ static void xen_vcpu_notify_restore(void
 
 static void xen_vcpu_notify_suspend(void *data)
 {
+   u64 tmp;
+
tick_suspend_local();
+
+   if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
+   rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
+   this_cpu_write(spec_ctrl, tmp);
+   wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+   }
 }
 
 void xen_arch_resume(void)



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

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

[Christian Lindig]

> On 9. Mar 2018, at 22:57, Michael Young  wrote:
> 
> I have had a go at fixing the patch and my revised attempt is attached. I 
> suspect it could be tidied up, but it works for me.

Thank you for giving this another go. What is the key difference to the 
previous patch which compiled but lead to lock up at run time? I briefly tried 
your patch and can confirm that it compiles and looks clean except for two 
trailing spaces. 

— Christian

Acked-by: Christian Lindig 



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

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

[Michael Young]

On Mon, 12 Feb 2018, Wei Liu wrote:


On Fri, Feb 09, 2018 at 09:20:33AM +, Christian Lindig wrote:




On 8. Feb 2018, at 18:24, Wei Liu  wrote:

Christian, do you have any idea when you can look into fixing the
safe-string patch?


Sorry, I can’t make a promise because of my other obligations. I do wonder, 
though: this patch did not come out of nowhere but supposedly was working - 
what is different here?



No worries. I have reverted some patches in xen.git to get things going
again.


I have had a go at fixing the patch and my revised attempt is attached. 
I suspect it could be tidied up, but it works for me.


Michael YoungFrom 550ffe177842e3fd9f38c78e07072fa7c7b591a5 Mon Sep 17 00:00:00 2001
From: Michael Young 
Date: Fri, 9 Mar 2018 22:31:41 +
Subject: [PATCH v3] make xen ocaml safe-strings compliant

Xen built with ocaml 4.06 gives errors such as
Error: This expression has type bytes but an expression was
expected of type string
as Byte and safe-strings which were introduced in 4.02 are the
default in 4.06.
This patch which is partly by Richard W.M. Jones of Red Hat
from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
fixes these issues.

v3: rework patches for xb.ml and /utils.ml to fix broken code relating
to Unix.read.  Update xb.mli to match changes in xb.ml.

Signed-off-by: Michael Young 

---
 tools/ocaml/libs/xb/xb.ml| 18 ++
 tools/ocaml/libs/xb/xb.mli   | 10 +-
 tools/ocaml/xenstored/logging.ml | 22 +++---
 tools/ocaml/xenstored/stdext.ml  |  2 +-
 tools/ocaml/xenstored/utils.ml   | 20 ++--
 5 files changed, 37 insertions(+), 35 deletions(-)

diff --git a/tools/ocaml/libs/xb/xb.ml b/tools/ocaml/libs/xb/xb.ml
index 50944b5fd6..42ae8d2bd8 100644
--- a/tools/ocaml/libs/xb/xb.ml
+++ b/tools/ocaml/libs/xb/xb.ml
@@ -40,7 +40,7 @@ type backend_fd =
 
 type backend = Fd of backend_fd | Xenmmap of backend_mmap
 
-type partial_buf = HaveHdr of Partial.pkt | NoHdr of int * string
+type partial_buf = HaveHdr of Partial.pkt | NoHdr of int * bytes
 
 type t =
 {
@@ -52,7 +52,7 @@ type t =
 }
 
 let init_partial_in () = NoHdr
-   (Partial.header_size (), String.make (Partial.header_size()) '\000')
+   (Partial.header_size (), Bytes.make (Partial.header_size()) '\000')
 
 let reconnect t = match t.backend with
| Fd _ ->
@@ -76,7 +76,9 @@ let read_fd back con s len =
rd
 
 let read_mmap back con s len =
-   let rd = Xs_ring.read back.mmap s len in
+   let stmp = String.make len (char_of_int 0) in
+   let rd = Xs_ring.read back.mmap stmp len in
+   Bytes.blit_string stmp 0 s 0 rd;
back.work_again <- (rd > 0);
if rd > 0 then
back.eventchn_notify ();
@@ -98,7 +100,7 @@ let write_mmap back con s len =
 
 let write con s len =
match con.backend with
-   | Fd backfd -> write_fd backfd con s len
+   | Fd backfd -> write_fd backfd con (Bytes.of_string s) len
| Xenmmap backmmap -> write_mmap backmmap con s len
 
 (* NB: can throw Reconnect *)
@@ -129,7 +131,7 @@ let input con =
| NoHdr   (i, buf)-> i in
 
(* try to get more data from input stream *)
-   let s = String.make to_read '\000' in
+   let s = Bytes.make to_read '\000' in
let sz = if to_read > 0 then read con s to_read else 0 in
 
(
@@ -137,7 +139,7 @@ let input con =
| HaveHdr partial_pkt ->
(* we complete the data *)
if sz > 0 then
-   Partial.append partial_pkt s sz;
+   Partial.append partial_pkt (Bytes.to_string s) sz;
if Partial.to_complete partial_pkt = 0 then (
let pkt = Packet.of_partialpkt partial_pkt in
con.partial_in <- init_partial_in ();
@@ -147,9 +149,9 @@ let input con =
| NoHdr (i, buf)  ->
(* we complete the partial header *)
if sz > 0 then
-   String.blit s 0 buf (Partial.header_size () - i) sz;
+   Bytes.blit s 0 buf (Partial.header_size () - i) sz;
con.partial_in <- if sz = i then
-   HaveHdr (Partial.of_string buf) else NoHdr (i - sz, buf)
+   HaveHdr (Partial.of_string (Bytes.to_string buf)) else 
NoHdr (i - sz, buf)
);
!newpacket
 
diff --git a/tools/ocaml/libs/xb/xb.mli b/tools/ocaml/libs/xb/xb.mli
index b4d705201f..d566011fc7 100644
--- a/tools/ocaml/libs/xb/xb.mli
+++ b/tools/ocaml/libs/xb/xb.mli
@@ -65,7 +65,7 @@ type backend_mmap = {
 }
 type backend_fd = { fd : Unix.file_descr; }
 type backend = Fd of backend_fd | Xenmmap of backend_mmap
-type partial_buf = HaveHdr of Partial.pkt | NoHdr of int * string
+type partial_buf = HaveHdr of Partial.pkt | NoHdr of int * bytes
 type t = {
   backend : backend;
   pkt_in : 

Re: [Xen-devel] Xen on POWER

[André Przywara]

On 09/03/18 13:35, awokd wrote:
> On Fri, March 9, 2018 11:52 am, awokd wrote:
> 
>> Xen on ARM might be a more reasonable starting point but I'm not sure
>> that would provide enough horsepower to drive a workstation

That's indeed an issue. There are ARM64 SoCs which are very capable and
could easily match or even outperform commodity Intel desktop hardware,
but no-one offers them in a desktop or workstation package. I guess the
seemingly dwindling desktop market is not very attractive to vendors.

>> and have
>> (possibly
>> unfounded) concerns about the platform following in x86's footsteps with
>> TrustZone and end-user lock out.
> 
> Sorry, didn't realize I was replying to someone @arm.com! My possibly
> mistaken perception is that ARM requires proprietary blobs and TrustZone
> provides a way to lock out end-users so they can't provide their own boot
> binaries. In some applications that's a good thing, but not for personal
> use.

That's a common misconception. Trustzone is the marketing name of a
rather innocent, but indeed quite clever architectural feature, namely
to separate the potentially vulnerable "non-secure" OS from some other
trusted code, for instance firmware. The neat property is that this
extends to hardware devices, which can be sorted into one of those two
groups. But how this is actually used is entirely up to the particular
platform.
The boot binary protection is a concept popular in embedded systems and
mobile phones, which is what ARM is often associated with.
But many server like systems (including storage or network focused
boards) run Open Source implementations of the firmware, for instance
the BSD licensed "ARM Trusted Firmware", developed on Github. This makes
the whole firmware on those boards replaceable and visitable. *Some*
systems may ship binary blobs, but this is mostly for system
initialization (DRAM training, platform setup) and the code won't stay
around at OS runtime. Eventually those could be replaced as well.
In fact on those systems you could actually use TrustZone to your
advantage, for instance for storing private keys in a place inaccessible
by the normal (read: hackable) OS, and only offering software interfaces
to encrypt data. The Open Source OP-TEE framework for instance is
exploring this direction.

> It's entirely possible I'm unfairly tarring ARM with the same x86 brush so
> if I'm mistaken on any of these aspects please feel free to correct me
> publicly.

No worries about that, and I actually didn't want to point you to ARM
platforms primarily (though this might have been a interesting side
effect. ;-)
I was just wondering if coming up with a whole new platform port of Xen
is the right and reasonable answer to you security concerns on your
existing platform. I very much fancy the idea of alternative platforms
(even non-ARM ;-), but it might be more worthwhile to support those
people who work on fixing or mitigating the existing problems (x86
binary blob firmware). Or even better: Piggy-back on the already
existing ARM64 port of Xen and help improving that.
Given from our experience there are many very detailed and intricate
problems to solve in such a platform port, especially since Power
deviates from both x86 and ARM in some ways (for instance paging and
TLBs). Also things like memory model and ordering, asynchronous
exceptions and tons of races in various places need to be considered.
Starting from scratch here sounds like a mammoth task, judging from the
bugs that we still discover on a somewhat weekly base here in the
existing Xen ports.
I don't want to steer you away from the Power on Xen port, it might
actually be beneficial to the Xen ecosystem, but if you are hoping for
having something usable in a year or so, you might be disappointed ;-)
At least without having the proper resources, to somewhat support
George's suggestions.

Cheers,
Andre.


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

[Xen-devel] [linux-4.1 test] 120338: regressions - FAIL

[osstest service owner]

flight 120338 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120338/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 6 kernel-build fail REGR. vs. 118294
 build-i386-pvops  6 kernel-build fail REGR. vs. 118294

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118294
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118294
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118294
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118294
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 

[Xen-devel] [PATCH v11 0/3] tools/libxc: use superpages

[Olaf Hering]

Using superpages on the receiving dom0 will avoid performance regressions.

Olaf

TODO:
 send 1G batches on HVM to help allocator on dst dom0

v11:
 rebase to and for 4.11
v10:
 coding style in xc_sr_bitmap API
 reset bitmap size on free
 check for empty bitmap in xc_sr_bitmap API
 add comment to struct x86_hvm_sp, keep the short name
 style and type changes in x86_hvm_punch_hole
 do not mark VGA hole as busy in x86_hvm_setup
 call decrease_reservation once for all pfns
 rename variable in x86_hvm_populate_pfns
 call decrease_reservation in 2MB chucks if possible
v9:
 update hole checking in x86_hvm_populate_pfns
 add out of bounds check to xc_sr_test_and_set/clear_bit
v8:
 remove double check of 1G/2M idx in x86_hvm_populate_pfns
v7:
 cover holes that span multiple superpages
v6:
 handle freeing of partly populated superpages correctly
 more DPRINTFs
v5:
 send correct version, rebase was not fully finished
v4:
 restore trailing "_bit" in bitmap function names
 keep track of gaps between previous and current batch
 split alloc functionality in x86_hvm_allocate_pfn
v3:
 clear pointer in xc_sr_bitmap_free
 some coding style changes
 use getdomaininfo.max_pages to avoid Over-allocation check
 trim bitmap function names, drop trailing "_bit"
 add some comments
v2:
 split into individual commits

based on staging c39cf093fc ("x86/asm: add .file directives")


Olaf Hering (3):
  tools/libxc: move SUPERPAGE macros to common header
  tools/libxc: add API for bitmap access for restore
  tools/libxc: use superpages during restore of HVM guest

 tools/libxc/xc_dom_x86.c|   5 -
 tools/libxc/xc_private.h|   5 +
 tools/libxc/xc_sr_common.c  |  41 +++
 tools/libxc/xc_sr_common.h  | 103 ++-
 tools/libxc/xc_sr_restore.c | 141 +-
 tools/libxc/xc_sr_restore_x86_hvm.c | 536 
 tools/libxc/xc_sr_restore_x86_pv.c  |  72 -
 7 files changed, 755 insertions(+), 148 deletions(-)


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

[Xen-devel] [PATCH v11 2/3] tools/libxc: add API for bitmap access for restore

[Olaf Hering]

Extend API for managing bitmaps. Each bitmap is now represented by a
generic struct xc_sr_bitmap.
Switch the existing populated_pfns to this API.

Signed-off-by: Olaf Hering 
Acked-by: Wei Liu 
---
 tools/libxc/xc_sr_common.c  | 41 +
 tools/libxc/xc_sr_common.h  | 73 +++--
 tools/libxc/xc_sr_restore.c | 66 ++--
 3 files changed, 115 insertions(+), 65 deletions(-)

diff --git a/tools/libxc/xc_sr_common.c b/tools/libxc/xc_sr_common.c
index 79b9c3e940..28c7be2b15 100644
--- a/tools/libxc/xc_sr_common.c
+++ b/tools/libxc/xc_sr_common.c
@@ -155,6 +155,47 @@ static void __attribute__((unused)) build_assertions(void)
 BUILD_BUG_ON(sizeof(struct xc_sr_rec_hvm_params)!= 8);
 }
 
+/*
+ * Expand the tracking structures as needed.
+ * To avoid realloc()ing too excessively, the size increased to the nearest 
power
+ * of two large enough to contain the required number of bits.
+ */
+bool _xc_sr_bitmap_resize(struct xc_sr_bitmap *bm, unsigned long bits)
+{
+if ( bits > bm->bits )
+{
+size_t new_max;
+size_t old_sz, new_sz;
+void *p;
+
+/* Round up to the nearest power of two larger than bit, less 1. */
+new_max = bits;
+new_max |= new_max >> 1;
+new_max |= new_max >> 2;
+new_max |= new_max >> 4;
+new_max |= new_max >> 8;
+new_max |= new_max >> 16;
+#ifdef __x86_64__
+new_max |= new_max >> 32;
+#endif
+
+old_sz = bitmap_size(bm->bits + 1);
+new_sz = bitmap_size(new_max + 1);
+p = realloc(bm->p, new_sz);
+if ( !p )
+return false;
+
+if (bm->p)
+memset(p + old_sz, 0, new_sz - old_sz);
+else
+memset(p, 0, new_sz);
+
+bm->p = p;
+bm->bits = new_max;
+}
+return true;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index a145a15301..6bd35681b7 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -172,6 +172,12 @@ struct xc_sr_x86_pv_restore_vcpu
 size_t basicsz, extdsz, xsavesz, msrsz;
 };
 
+struct xc_sr_bitmap
+{
+void *p;
+unsigned long bits;
+};
+
 struct xc_sr_context
 {
 xc_interface *xch;
@@ -253,8 +259,7 @@ struct xc_sr_context
 uint32_t xenstore_domid,  console_domid;
 
 /* Bitmap of currently populated PFNs during restore. */
-unsigned long *populated_pfns;
-xen_pfn_t max_populated_pfn;
+struct xc_sr_bitmap populated_pfns;
 
 /* Sender has invoked verify mode on the stream. */
 bool verify;
@@ -341,6 +346,70 @@ extern struct xc_sr_save_ops save_ops_x86_hvm;
 extern struct xc_sr_restore_ops restore_ops_x86_pv;
 extern struct xc_sr_restore_ops restore_ops_x86_hvm;
 
+bool _xc_sr_bitmap_resize(struct xc_sr_bitmap *bm, unsigned long bits);
+
+static inline bool xc_sr_bitmap_resize(struct xc_sr_bitmap *bm, unsigned long 
bits)
+{
+if ( bits > bm->bits )
+return _xc_sr_bitmap_resize(bm, bits);
+return true;
+}
+
+static inline void xc_sr_bitmap_free(struct xc_sr_bitmap *bm)
+{
+free( bm->p );
+bm->bits = 0;
+bm->p = NULL;
+}
+
+static inline bool xc_sr_set_bit(unsigned long bit, struct xc_sr_bitmap *bm)
+{
+if ( !xc_sr_bitmap_resize(bm, bit) )
+return false;
+
+set_bit(bit, bm->p);
+return true;
+}
+
+static inline bool xc_sr_test_bit(unsigned long bit, struct xc_sr_bitmap *bm)
+{
+if ( bit > bm->bits || !bm->bits )
+return false;
+return !!test_bit(bit, bm->p);
+}
+
+static inline bool xc_sr_test_and_clear_bit(unsigned long bit, struct 
xc_sr_bitmap *bm)
+{
+if ( bit > bm->bits || !bm->bits )
+return false;
+return !!test_and_clear_bit(bit, bm->p);
+}
+
+static inline bool xc_sr_test_and_set_bit(unsigned long bit, struct 
xc_sr_bitmap *bm)
+{
+if ( bit > bm->bits || !bm->bits )
+return false;
+return !!test_and_set_bit(bit, bm->p);
+}
+
+static inline bool pfn_is_populated(struct xc_sr_context *ctx, xen_pfn_t pfn)
+{
+return xc_sr_test_bit(pfn, >restore.populated_pfns);
+}
+
+static inline int pfn_set_populated(struct xc_sr_context *ctx, xen_pfn_t pfn)
+{
+xc_interface *xch = ctx->xch;
+
+if ( !xc_sr_set_bit(pfn, >restore.populated_pfns) )
+{
+ERROR("Failed to realloc populated_pfns bitmap");
+errno = ENOMEM;
+return -1;
+}
+return 0;
+}
+
 struct xc_sr_record
 {
 uint32_t type;
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index ea7b0339ef..0c56c40e7a 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -68,64 +68,6 @@ static int read_headers(struct xc_sr_context *ctx)
 return 0;
 }
 
-/*
- * Is a pfn populated?
- */
-static bool pfn_is_populated(const struct xc_sr_context *ctx, xen_pfn_t 

[Xen-devel] [PATCH v11 1/3] tools/libxc: move SUPERPAGE macros to common header

[Olaf Hering]

The macros SUPERPAGE_2MB_SHIFT and SUPERPAGE_1GB_SHIFT will be used by
other code in libxc. Move the macros to a header file.

Signed-off-by: Olaf Hering 
Acked-by: Wei Liu 
---
 tools/libxc/xc_dom_x86.c | 5 -
 tools/libxc/xc_private.h | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0b65dab4bc..d0b9057af5 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -43,11 +43,6 @@
 
 #define SUPERPAGE_BATCH_SIZE 512
 
-#define SUPERPAGE_2MB_SHIFT   9
-#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
-#define SUPERPAGE_1GB_SHIFT   18
-#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
-
 #define X86_CR0_PE 0x01
 #define X86_CR0_ET 0x10
 
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 03bc9a7776..ee8de4e8d4 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -66,6 +66,11 @@ struct iovec {
 #define DECLARE_FLASK_OP struct xen_flask_op op
 #define DECLARE_PLATFORM_OP struct xen_platform_op platform_op
 
+#define SUPERPAGE_2MB_SHIFT   9
+#define SUPERPAGE_2MB_NR_PFNS (1UL << SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT   18
+#define SUPERPAGE_1GB_NR_PFNS (1UL << SUPERPAGE_1GB_SHIFT)
+
 #undef PAGE_SHIFT
 #undef PAGE_SIZE
 #undef PAGE_MASK

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

[Xen-devel] [xen-unstable-smoke test] 120372: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  185413355fe331cbc926d48568838227234c9a20
baseline version:
 xen  ca8c67629a509f45e83ebdb0f679b692707ad7d9

Last test of basis   120370  2018-03-09 14:01:12 Z0 days
Testing same since   120372  2018-03-09 17:06:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Martin Cerveny 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   ca8c67629a..185413355f  185413355fe331cbc926d48568838227234c9a20 -> smoke

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

Re: [Xen-devel] [RFC PATCH 0/5] x86: Multiple fixes to MSR_TSC_AUX and RDTSCP handling for guests

[Boris Ostrovsky]

On 03/09/2018 01:41 PM, Andrew Cooper wrote:

On 09/03/2018 18:05, Boris Ostrovsky wrote:



On 02/26/2018 06:30 PM, Andrew Cooper wrote:

On 26/02/2018 19:44, Boris Ostrovsky wrote:

On 02/26/2018 02:12 PM, Andrew Cooper wrote:

On 20/02/18 11:58, Andrew Cooper wrote:

This rats nest was discovered when finding that MSR_TSC_AUX leaked
into PV
guests.  It is RFC because I haven't done extensive testing on the
result, and
because there are some functional changes for the virtualised TSC
modes.

Andrew Cooper (5):
    x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()
    x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV
context
    x86/time: Rework pv_soft_rdtsc() to aid further cleanup
    x86/pv: Remove deferred RDTSC{,P} handling in
pv_emulate_privileged_op()
    x86: Rework MSR_TSC_AUX handling from scratch.

Konrad/Boris: Can we have any input WRT TSC_MODE_PVRDTSCP usage?  Are
you still using the feature, or is it abandoned?

I already asked a few internal teams about, haven't heard back.


Ah ok - thanks.  I'll wait to hear back from you then.



Took longer than I hoped, sorry.

Couldn't find anyone who is still using this mode (or perhaps noone
wanted to admit to this ;-)).


Is this your (Oracle's) blessing to purge the feature and pretend that
it never existed?



Not sure about the second part but for the first part (purging) --- sure.

-boris

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

Re: [Xen-devel] [PATCH v4] new config option vtsc_tolerance_khz to avoid TSC emulation

[Daniel De Graaf]

On 03/09/2018 09:10 AM, Olaf Hering wrote:

Add an option to control when vTSC emulation will be activated for a
domU with tsc_mode=default. Without such option each TSC access from
domU will be emulated, which causes a significant perfomance drop for
workloads that make use of rdtsc.

Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to adjust the
tolerance value of a running domU that is supposed to be migrated.

One option to avoid the TSC option is to run domUs with tsc_mode=native.
This has the drawback that migrating a domU from a "2.3GHz" class host
to a "2.4GHz" class host may change the rate at wich the TSC counter
increases, the domU may not be prepared for that.

With this option the host admin can decide how a domU should behave when
it is migrated across systems of the same class. Since there is always
some jitter when Xen calibrates the cpu_khz value, all hosts of the same
class will most likely have slightly different values. As a result vTSC
emulation is unavoidable. Data collected during the incident which
triggered this change showed a jitter of up to 200 KHz across systems of
the same class.

A new utility is added which allows to adjust the vtsc_tolerance_khz
value for running domUs. This is useful to avoid emulation for domUs
that are already running and which can not be restarted.

The ordering of records sent during migration is important. The value of
vtsc_tolerance_khz must be known by the receiving host before
configuring TSC, because this is the place where the decision of vTSC
emulation is made. Therefore the existing write_tsc_info function is
modified to enforce that ordering.

v4:
  - add missing copyback in XEN_DOMCTL_set_vtsc_tolerance_khz
v3:
  - rename vtsc_khz_tolerance to vtsc_tolerance_khz
  - separate domctls to adjust values
  - more docs
  - update libxl.h
  - update python tests
  - flask check bound to tsc permissions
  - not runtime tested due to dlsym() build errors in staging

Signed-off-by: Olaf Hering 


Acked-by: Daniel De Graaf 

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

[Xen-devel] [qemu-mainline test] 120318: regressions - FAIL

[osstest service owner]

flight 120318 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120318/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1   fail REGR. vs. 120095
 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 120095
 test-arm64-arm64-xl-credit2  10 debian-install   fail REGR. vs. 120095

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 120095
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 120095
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120095
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120095
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 120095
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 120095
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuuf32408f3b472a088467474ab152be3b6285b2d7b
baseline version:
 qemuu6697439794f72b3501ee16bb95d16854f9981421

Last test of basis   120095  2018-02-28 13:46:33 Z9 days
Failing since120146  2018-03-02 10:10:57 Z7 days4 attempts
Testing same since   120318  2018-03-07 20:31:28 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alistair Francis 
  Alistair Francis 
  Anton Nefedov 
  BALATON Zoltan 
  Bastian Koppelmann 
  Christian Borntraeger 
  Collin L. Walling 
  Corey Minyard 

Re: [Xen-devel] [PATCH 56/57] ARM: allocate two pages for struct vcpu

[Julien Grall]

Hi,

On 05/03/18 16:04, Andre Przywara wrote:

At the moment we allocate exactly one page for struct vcpu on ARM, also
have a check in place to prevent it growing beyond 4KB.
As the struct includes the state of all 32 private (per-VCPU) interrupts,
we are at 3840 bytes on arm64 at the moment already. Growing the per-IRQ
VGIC structure even slightly makes the VCPU quickly exceed the 4K limit.
The new VGIC will need more space per virtual IRQ. I spent a few hours
trying to trim this down, but couldn't get it below 4KB, even with the
nasty hacks piling up to save some bytes here and there.
It turns out that beyond efficiency, maybe, there is no real technical
reason this struct has to fit in one page, so lifting the limit to two
pages seems like the most pragmatic solution.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- no changes

  xen/arch/arm/domain.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 11a46aa27f..0bec6aad17 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -502,10 +502,13 @@ void dump_pageframe_info(struct domain *d)
  struct vcpu *alloc_vcpu_struct(void)
  {
  struct vcpu *v;
-BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE);
-v = alloc_xenheap_pages(0, 0);
-if ( v != NULL )
+
+BUILD_BUG_ON(sizeof(*v) > 2 * PAGE_SIZE);
+v = alloc_xenheap_pages(1, 0);


While I am still not a big fan of increasing struct vcpu. We should at 
least not blindly increase it for anyone. There are indeed some setup 
where the 8KB solution is not necessary. This is the case of Arm32, and 
Arm64 (with the old vGIC).


I would also like to hear Stefano's opinion on that one.


+if ( v != NULL ) {
  clear_page(v);
+clear_page((void *)v + PAGE_SIZE);
+}
  return v;
  }
  



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 55/57] ARM: new VGIC: Add vgic_v2_enable

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

Enable the VGIC operation by properly initialising the registers
in the hypervisor GIC interface.

This is based on Linux commit f7b6985cc3d0, written by Eric Auger.

Signed-off-by: Andre Przywara 


Would you mind to move that patch before #53? This feels more logical as 
the first user in there.



---
Changelog RFC ... v1:
- drop unneeded vgic_vmcr initialization
- use update_hcr_status wrapper

  xen/arch/arm/vgic/vgic-v2.c | 6 ++
  xen/arch/arm/vgic/vgic.h| 1 +
  2 files changed, 7 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
index da64b4758c..b7d6493e5a 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -221,6 +221,12 @@ void vgic_v2_populate_lr(struct vcpu *vcpu, struct 
vgic_irq *irq, int lr)
  gic_hw_ops->write_lr(lr, _val);
  }
  
+void vgic_v2_enable(struct vcpu *vcpu)

+{
+/* Get the show on the road... */
+gic_hw_ops->update_hcr_status(GICH_HCR_EN, 1);
+}
+
  int vgic_v2_map_resources(struct domain *d)
  {
  struct vgic_dist *dist = >arch.vgic;
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index 6fab994b9c..bd0c3fe5ab 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -61,6 +61,7 @@ void vgic_sync_hardware_irq(struct domain *d,
  void vgic_v2_fold_lr_state(struct vcpu *vcpu);
  void vgic_v2_populate_lr(struct vcpu *vcpu, struct vgic_irq *irq, int lr);
  void vgic_v2_set_underflow(struct vcpu *vcpu);
+void vgic_v2_enable(struct vcpu *vcpu);
  int vgic_v2_map_resources(struct domain *d);
  int vgic_register_dist_iodev(struct domain *d, gfn_t dist_base_fn,
   enum vgic_type);



Cheers,

--
Julien Grall

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

[Xen-devel] [GIT PULL] xen: fix for V4.16-rc5

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.16a-rc5-tag

xen: fix for V4.16-rc5

It contains just one fix for the correct error handling after a negative
rc from device_register().


Thanks.

Juergen

 drivers/xen/xenbus/xenbus_probe.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

Arvind Yadav (1):
  xen: xenbus: use put_device() instead of kfree()

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

Re: [Xen-devel] [PATCH 54/57] ARM: new VGIC: vgic-init: implement map_resources

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

map_resources is the last initialization step needed before the first
VCPU is run. At that stage the code stores the MMIO base addresses used.
Also it registers the respective register frames with the MMIO framework.

This is based on Linux commit cbae53e663ea, written by Eric Auger.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- adapting to previous changes

  xen/arch/arm/vgic/vgic-v2.c | 66 +
  xen/arch/arm/vgic/vgic.h|  1 +
  2 files changed, 67 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
index 4e74ebf7f5..da64b4758c 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -221,6 +221,72 @@ void vgic_v2_populate_lr(struct vcpu *vcpu, struct 
vgic_irq *irq, int lr)
  gic_hw_ops->write_lr(lr, _val);
  }
  
+int vgic_v2_map_resources(struct domain *d)

+{
+struct vgic_dist *dist = >arch.vgic;
+paddr_t cbase, csize;
+paddr_t vbase;
+int ret;
+
+/*
+ * The hardware domain gets the hardware address.
+ * Guests get the virtual platform layout.
+ */
+if ( is_hardware_domain(d) )
+{
+d->arch.vgic.vgic_dist_base = gic_v2_hw_data.dbase;
+/*
+ * For the hardware domain, we always map the whole HW CPU
+ * interface region in order to match the device tree (the "reg"
+ * properties is copied as it is).
+ * Note that we assume the size of the CPU interface is always
+ * aligned to PAGE_SIZE.
+ */
+cbase = gic_v2_hw_data.cbase;   /* was: dist->vgic_cpu_base */
+csize = gic_v2_hw_data.csize;
+vbase = gic_v2_hw_data.vbase; /* was: kvm_vgic_global_state.vcpu_base 
*/


NIT: Please keep the comment indented the same way.


+}
+else
+{
+d->arch.vgic.vgic_dist_base = GUEST_GICD_BASE;
+/*
+ * The CPU interface exposed to the guest is always 8kB. We may
+ * need to add an offset to the virtual CPU interface base
+ * address when in the GIC is aliased to get a 8kB contiguous
+ * region.
+ */
+BUILD_BUG_ON(GUEST_GICC_SIZE != SZ_8K);
+cbase = GUEST_GICC_BASE;
+csize = GUEST_GICC_SIZE;
+vbase = gic_v2_hw_data.vbase + gic_v2_hw_data.aliased_offset;
+}
+
+
+ret = vgic_register_dist_iodev(d, gaddr_to_gfn(dist->vgic_dist_base),
+   VGIC_V2);
+if ( ret )
+{
+gdprintk(XENLOG_ERR, "Unable to register VGIC MMIO regions\n");
+return ret;
+}
+
+/*
+ * Map the gic virtual cpu interface in the gic cpu interface
+ * region of the guest.
+ */
+ret = map_mmio_regions(d, gaddr_to_gfn(cbase), csize / PAGE_SIZE,
+   maddr_to_mfn(vbase));


Indentation.


+if ( ret )
+{
+gdprintk(XENLOG_ERR, "Unable to remap VGIC CPU to VCPU\n");
+return ret;
+}
+
+dist->ready = true;
+
+return 0;
+}
+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index f19dc9502f..6fab994b9c 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -61,6 +61,7 @@ void vgic_sync_hardware_irq(struct domain *d,
  void vgic_v2_fold_lr_state(struct vcpu *vcpu);
  void vgic_v2_populate_lr(struct vcpu *vcpu, struct vgic_irq *irq, int lr);
  void vgic_v2_set_underflow(struct vcpu *vcpu);
+int vgic_v2_map_resources(struct domain *d);
  int vgic_register_dist_iodev(struct domain *d, gfn_t dist_base_fn,
   enum vgic_type);
  



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 53/57] ARM: new VGIC: vgic-init: implement vgic_init

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

This patch allocates and initializes the data structures used to model
the vgic distributor and virtual cpu interfaces. At that stage the
number of IRQs and number of virtual CPUs is frozen.
Implement the various functions that the Xen arch code is expecting to
call during domain and VCPU setup to initialize the VGIC.
Their prototypes are already in existing header files.

This is based on Linux commit ad275b8bb1e6, written by Eric Auger.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- adapt to former changes
- add missing comment line
- extend commit message

  xen/arch/arm/vgic/vgic-init.c | 196 ++
  1 file changed, 196 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
index d091c92ed0..8bc83f677b 100644
--- a/xen/arch/arm/vgic/vgic-init.c
+++ b/xen/arch/arm/vgic/vgic-init.c
@@ -20,6 +20,77 @@
  
  #include "vgic.h"
  
+/*

+ * Initialization rules: there are multiple stages to the vgic
+ * initialization, both for the distributor and the CPU interfaces.  The basic
+ * idea is that even though the VGIC is not functional or not requested from
+ * user space, the critical path of the run loop can still call VGIC functions
+ * that just won't do anything, without them having to check additional
+ * initialization flags to ensure they don't look at uninitialized data
+ * structures.
+ *
+ * Distributor:
+ *
+ * - vgic_early_init(): initialization of static data that doesn't
+ *   depend on any sizing information or emulation type. No allocation
+ *   is allowed there.
+ *
+ * - vgic_init(): allocation and initialization of the generic data
+ *   structures that depend on sizing information (number of CPUs,
+ *   number of interrupts). Also initializes the vcpu specific data
+ *   structures. Can be executed lazily for GICv2.
+ *
+ * CPU Interface:
+ *
+ * - kvm_vgic_vcpu_early_init(): initialization of static data that
+ *   doesn't depend on any sizing information or emulation type. No
+ *   allocation is allowed there.
+ */
+
+/**
+ * vgic_vcpu_early_init() - Initialize static VGIC VCPU data structures
+ * @vcpu: The VCPU whose VGIC data structures whould be initialized
+ *
+ * Only do initialization, but do not actually enable the VGIC CPU interface
+ * yet.
+ */
+static void vgic_vcpu_early_init(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = >arch.vgic;
+int i;


unsigned please.


+
+INIT_LIST_HEAD(_cpu->ap_list_head);
+spin_lock_init(_cpu->ap_list_lock);


Do we need something similar to 23b40df6f098e3bcb2f105a4909860240976e40f 
"xen/arm: vgic: Make sure the number of SPIs is a multiple of 32"?



+
+/*
+ * Enable and configure all SGIs to be edge-triggered and
+ * configure all PPIs as level-triggered.
+ */
+for ( i = 0; i < VGIC_NR_PRIVATE_IRQS; i++ )
+{
+struct vgic_irq *irq = _cpu->private_irqs[i];
+
+INIT_LIST_HEAD(>ap_list);
+spin_lock_init(>irq_lock);
+irq->intid = i;
+irq->vcpu = NULL;
+irq->target_vcpu = vcpu;
+irq->targets = 1U << vcpu->vcpu_id;
+atomic_set(>refcount, 0);
+if ( vgic_irq_is_sgi(i) )
+{
+/* SGIs */
+irq->enabled = 1;
+irq->config = VGIC_CONFIG_EDGE;
+}
+else
+{
+/* PPIs */
+irq->config = VGIC_CONFIG_LEVEL;
+}
+}
+}
+
  /* CREATION */
  
  /**

@@ -50,6 +121,131 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
  return 0;
  }
  
+/* INIT/DESTROY */

+
+/**
+ * domain_vgic_init: initialize the dist data structures
+ * @d: domain pointer
+ * @nr_spis: number of SPIs
+ */
+int domain_vgic_init(struct domain *d, unsigned int nr_spis)
+{
+struct vgic_dist *dist = >arch.vgic;
+int i, ret;


Ditto for i.


+
+/* Limit the number of virtual SPIs supported to (1020 - 32) = 988  */
+if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
+return -EINVAL;
+
+dist->nr_spis = nr_spis;
+dist->spis = xzalloc_array(struct vgic_irq, nr_spis);
+if ( !dist->spis )
+return  -ENOMEM;
+
+/*
+ * In the following code we do not take the irq struct lock since
+ * no other action on irq structs can happen while the VGIC is
+ * not initialized yet:
+ * If someone wants to inject an interrupt or does a MMIO access, we
+ * require prior initialization in case of a virtual GICv3 or trigger
+ * initialization when using a virtual GICv2.
+ */
+for ( i = 0; i < nr_spis; i++ )
+{
+struct vgic_irq *irq = >spis[i];
+
+irq->intid = i + VGIC_NR_PRIVATE_IRQS;
+INIT_LIST_HEAD(>ap_list);
+spin_lock_init(>irq_lock);
+irq->vcpu = NULL;
+irq->target_vcpu = NULL;
+atomic_set(>refcount, 0);
+if ( dist->version == GIC_V2 )
+irq->targets = 0;
+else
+irq->mpidr 

Re: [Xen-devel] [PATCH 51/57] ARM: new VGIC: Add preliminary stub implementation

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

The ARM arch code requires an interrupt controller emulation to implement
vgic_clear_pending_irqs(), although it is suspected that it is actually
not necessary. Go with a stub for now to make the linker happy.


The implementation of that function is fundamentally wrong on the 
current vGIC for a few reasons:
	- lr_mask is reset but the LRs are not. This means when we context 
switch back, the LR might still be written and injecting unexpected 
interrupt (whoops).
	- both lists (inflight and pending) are cleared which means that a 
physical interrupt pending on that vCPU is lost forever (stay active in 
the physical so never going to fire again).


Furthermore, I don't think that Xen business to reset the GIC on cpu_on. 
If anything should be done, then is it on CPU_off to migrate the current 
interrupts to another vCPU. But IIRC the OS is responsible for that.


So I would kill that function. Any opinions?



Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- split off from former patch, otherwise unchanged

  xen/arch/arm/vgic/vgic.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 5e767927c0..5d84a4d81a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -790,6 +790,14 @@ void gic_dump_vgic_info(struct vcpu *v)
  spin_unlock_irqrestore(>arch.vgic.ap_list_lock, flags);
  }
  
+void vgic_clear_pending_irqs(struct vcpu *v)

+{
+/*
+ * TODO: It is unclear whether we really need this, so we might instead
+ * remove it on the caller site.
+ */
+}
+
  /**
   * arch_move_irqs() - migrate the physical affinity of hardware mapped vIRQs
   * @v:  the vCPU, already assigned to the new pCPU



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 0/5] x86: Multiple fixes to MSR_TSC_AUX and RDTSCP handling for guests

[Boris Ostrovsky]

On 02/26/2018 06:30 PM, Andrew Cooper wrote:

On 26/02/2018 19:44, Boris Ostrovsky wrote:

On 02/26/2018 02:12 PM, Andrew Cooper wrote:

On 20/02/18 11:58, Andrew Cooper wrote:

This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV
guests.  It is RFC because I haven't done extensive testing on the result, and
because there are some functional changes for the virtualised TSC modes.

Andrew Cooper (5):
   x86/hvm: Don't shadow the domain parameter in hvm_save_cpu_msrs()
   x86/pv: Avoid leaking other guests' MSR_TSC_AUX values into PV context
   x86/time: Rework pv_soft_rdtsc() to aid further cleanup
   x86/pv: Remove deferred RDTSC{,P} handling in pv_emulate_privileged_op()
   x86: Rework MSR_TSC_AUX handling from scratch.

Konrad/Boris: Can we have any input WRT TSC_MODE_PVRDTSCP usage?  Are
you still using the feature, or is it abandoned?

I already asked a few internal teams about, haven't heard back.


Ah ok - thanks.  I'll wait to hear back from you then.



Took longer than I hoped, sorry.

Couldn't find anyone who is still using this mode (or perhaps noone 
wanted to admit to this ;-)).


-boris


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

Re: [Xen-devel] [PATCH 2/2] x86: use invpcid to do global flushing

[Juergen Gross]

On 09/03/18 16:29, Jan Beulich wrote:
 On 05.03.18 at 10:50,  wrote:
>> @@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va, unsigned 
>> int flags)
>>  else
>>  {
>>  u32 t = pre_flush();
>> -unsigned long cr4 = read_cr4();
>>  
>> -write_cr4(cr4 & ~X86_CR4_PGE);
>> -barrier();
>> -write_cr4(cr4);
>> +if ( !cpu_has_invpcid )
>> +{
>> +unsigned long cr4 = read_cr4();
>> +
>> +write_cr4(cr4 & ~X86_CR4_PGE);
>> +barrier();
>> +write_cr4(cr4);
>> +}
>> +else
>> +{
>> +/*
>> + * Using invpcid to flush all mappings works
>> + * regardless of whether PCID is enabled or not.
>> + * It is faster than read-modify-write CR4.
>> + */
>> +invpcid_flush_all();
>> +}
> 
> As just validly indicated by Jürgen, this is where my comment I
> gave to one of his patches actually belongs: This is correct for
> FLUSH_TLB_GLOBAL, but goes too far for FLUSH_TLB.

And again it was so even before this patch.


Juergen

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

[Xen-devel] [PATCH 1/3] SUPPORT.md: Clarify that the PV keyboard protocol includes mouse support

[George Dunlap]

s/fo/fo; while we're here.

Signed-off-by: George Dunlap 
---
This is a candidate for backport to 4.10.

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Konrad Wilk 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Anthony Perard 
CC: Paul Durrant 
CC: Lars Kurth 
---
 SUPPORT.md | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index a1810b8046..87d07129b4 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -380,7 +380,8 @@ Guest-side driver capable of speaking the Xen PV console 
protocol
 
 Status, Linux (xen-kbdfront): Supported
 
-Guest-side driver capable of speaking the Xen PV keyboard protocol
+Guest-side driver capable of speaking the Xen PV keyboard protocol.
+Note that the "keyboard protocol" includes mouse / pointer support as well.
 
 ### PV USB (frontend)
 
@@ -451,7 +452,8 @@ Host-side implementation of the Xen PV console protocol
 
 Status, QEMU: Supported
 
-Host-side implementation fo the Xen PV keyboard protocol
+Host-side implementation of the Xen PV keyboard protocol.
+Note that the "keyboard protocol" includes mouse / pointer support as well.
 
 ### PV USB (backend)
 
-- 
2.16.2


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

[Xen-devel] [PATCH 3/3] docs: Remove redundant qemu-xen-security document

[George Dunlap]

All this information is now covered in SUPPORT.md.

Most of the emulated hardware is obvious a couple of the items are
worth pointing out specifically.

"xen_disk" is listed under "Blkback"

"...the PCI host bridge and the PIIX3 chipset...": This statement is
redundant -- the PCI host bridge is a part of the piix3 chipset, which
is listed as supported.

xenfb: The "graphics" side of "xenfb" is listed under "PV Framebuffer
(backend)", and the "input" side of "xenfb" (including both keyboard
and mouse) is listed under "PV Keyboard (backend)".

Backing storage image format is listed in the "Blkback" section.

Signed-off-by: George Dunlap 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Konrad Wilk 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Anthony Perard 
CC: Lars Kurth 
---
 docs/misc/qemu-xen-security | 21 -
 1 file changed, 21 deletions(-)
 delete mode 100644 docs/misc/qemu-xen-security

diff --git a/docs/misc/qemu-xen-security b/docs/misc/qemu-xen-security
deleted file mode 100644
index 496f7eee7a..00
--- a/docs/misc/qemu-xen-security
+++ /dev/null
@@ -1,21 +0,0 @@
-qemu-xen (git://xenbits.xen.org/qemu-xen.git) is only supported for
-security fixes when used together with the Xen hypervisor and only with
-a subset of all the possible QEMU emulators. Specifically:
-
-- network: e1000, rtl8139, virtio-net
-- storage: piix3 ide, ahci, xen_disk
-- backing storage image format: raw, qcow, qcow2, vhd
-- graphics: cirris-vga, stdvga and xenfb
-- audio: sb16, es1370, ac97
-- input: Xen PV keyboard and mouse (part of xenfb), USB and PS/2
- keyboard and mouse
-- serial cards: UART 16550A
-
-Core components, such as the PCI host bridge and the PIIX3 chipset, are
-supported. All devices of one the above classes, which are not explicitly
-mentioned, are not supported. For example the ne2000 network card is not
-supported. 
-
-If you think that a specific emulated device should be supported, please
-contact the QEMU UPSTREAM maintainer and the Xen Security Team
-(secur...@xenproject.org).
-- 
2.16.2


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

Re: [Xen-devel] [PATCH 50/57] ARM: new VGIC: Implement arch_move_irqs()

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

When a VCPU moves to another CPU, we need to adjust the target affinity
of any hardware mapped vIRQs, to observe our "physical-follows-virtual"
policy.
Implement arch_move_irqs() to adjust the physical affinity of all hardware
mapped vIRQs targetting this VCPU.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- actually implement arch_move_irqs() (instead of just stubbing it)

  xen/arch/arm/vgic/vgic.c | 42 ++
  1 file changed, 42 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index e1952c872d..5e767927c0 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -790,6 +790,48 @@ void gic_dump_vgic_info(struct vcpu *v)
  spin_unlock_irqrestore(>arch.vgic.ap_list_lock, flags);
  }
  
+/**

+ * arch_move_irqs() - migrate the physical affinity of hardware mapped vIRQs
+ * @v:  the vCPU, already assigned to the new pCPU
+ *
+ * arch_move_irqs() updates the physical affinity of all virtual IRQs
+ * targetting this given vCPU. This only affects hardware mapped IRQs. The
+ * new pCPU to target is already set in v->processor.
+ * This is called by the core code after a vCPU has been migrated to a new
+ * physical CPU.
+ */
+void arch_move_irqs(struct vcpu *v)
+{
+struct domain *d = v->domain;
+unsigned int i;
+
+/* We only target SPIs with this function */
+for ( i = 0; i < d->arch.vgic.nr_spis; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(d, NULL, i + VGIC_NR_PRIVATE_IRQS);
+unsigned long flags;
+irq_desc_t *desc;
+
+if ( !irq )
+continue;
+
+spin_lock_irqsave(>irq_lock, flags);
+
+/* only vIRQs that are not on a vCPU yet , but targetting this vCPU */
+if ( irq->hw && !irq->vcpu && irq->target_vcpu == v)
+desc = irq_to_desc(irq->hwintid);
+else
+desc = NULL;
+
+spin_unlock_irqrestore(>irq_lock, flags);
+
+if ( desc )
+vgic_sync_hardware_irq(d, desc, irq);


You want to look at my comment about using vgic_sync_hardware_irq for 
routing on patch #43.



+
+vgic_put_irq(d, irq);
+}
+}
+
  struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
unsigned int virq)
  {



Cheers,
--
Julien Grall

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

Re: [Xen-devel] [PATCH 49/57] ARM: new VGIC: provide system register emulation stub

[Julien Grall]

On 05/03/18 16:04, Andre Przywara wrote:

The Xen arch code traps system registers writes from the guest and will
relay anything GIC related to the VGIC.
Since this affects only GICv3 (which we don't yet emulate), provide a
stub implementation of vgic_emulate() for now.

Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,


---
Changelog RFC ... v1:
- no changes

  xen/arch/arm/vgic/vgic.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 2a2b8fd1eb..e1952c872d 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -813,6 +813,13 @@ struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, 
struct vcpu *v,
  return desc;
  }
  
+bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)

+{
+ASSERT(current->domain->arch.vgic.version == GIC_V3);
+
+return false;
+}
+
  /*
   * was:
   *  int kvm_vgic_map_phys_irq(struct vcpu *vcpu, u32 virt_irq, u32 
phys_irq)



--
Julien Grall

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

Re: [Xen-devel] [PATCH 48/57] ARM: new VGIC: Dump virtual IRQ info

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

When we dump guest state on the Xen console, we also print the state of
IRQs that are on a VCPU.
Add the code to dump the state of an IRQ handled by the new VGIC.

Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,


---
Changelog RFC ... v1:
- use proper locking
- use one header line to announce active or pending IRQs

  xen/arch/arm/vgic/vgic.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index e9ef992e1e..2a2b8fd1eb 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -765,6 +765,31 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
  clear_bit(virq, d->arch.vgic.allocated_irqs);
  }
  
+void gic_dump_vgic_info(struct vcpu *v)

+{
+struct vgic_cpu *vgic_cpu = >arch.vgic;
+struct vgic_irq *irq;
+unsigned long flags;
+
+spin_lock_irqsave(>arch.vgic.ap_list_lock, flags);
+
+if ( !list_empty(_cpu->ap_list_head) )
+printk("   active or pending interrupts queued:\n");
+
+list_for_each_entry ( irq, _cpu->ap_list_head, ap_list )
+{
+spin_lock(>irq_lock);
+printk(" %s %s irq %u: %spending, %sactive, %senabled\n",
+   irq->hw ? "hardware" : "virtual",
+   irq->config == VGIC_CONFIG_LEVEL ? "level" : "edge",
+   irq->intid, irq_is_pending(irq) ? "" : "not ",
+   irq->active ? "" : "not ", irq->enabled ? "" : "not ");
+spin_unlock(>irq_lock);
+}
+
+spin_unlock_irqrestore(>arch.vgic.ap_list_lock, flags);
+}
+
  struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
unsigned int virq)
  {



--
Julien Grall

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

Re: [Xen-devel] [PATCH 47/57] ARM: new VGIC: Handle virtual IRQ allocation/reservation

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

To find an unused virtual IRQ number Xen uses a scheme to track used
virtual IRQs.
Implement this interface in the new VGIC to make the Xen core/arch code
happy.
This is actually somewhat VGIC agnostic, so is mostly a copy of the code
from the old VGIC. But it has to live in the VGIC files, so we can't
easily reuse the existing implementation.

Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,


---
Changelog RFC ... v1:
- no changes

  xen/arch/arm/vgic/vgic.c | 44 
  1 file changed, 44 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 0bf257c865..e9ef992e1e 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -721,6 +721,50 @@ bool vgic_evtchn_irq_pending(struct vcpu *v)
  return pending;
  }
  
+bool vgic_reserve_virq(struct domain *d, unsigned int virq)

+{
+if ( virq >= vgic_num_irqs(d) )
+return false;
+
+return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
+}
+
+int vgic_allocate_virq(struct domain *d, bool spi)
+{
+int first, end;
+unsigned int virq;
+
+if ( !spi )
+{
+/* We only allocate PPIs. SGIs are all reserved */
+first = 16;
+end = 32;
+}
+else
+{
+first = 32;
+end = vgic_num_irqs(d);
+}
+
+/*
+ * There is no spinlock to protect allocated_irqs, therefore
+ * test_and_set_bit may fail. If so retry it.
+ */
+do
+{
+virq = find_next_zero_bit(d->arch.vgic.allocated_irqs, end, first);
+if ( virq >= end )
+return -1;
+} while ( test_and_set_bit(virq, d->arch.vgic.allocated_irqs) );
+
+return virq;
+}
+
+void vgic_free_virq(struct domain *d, unsigned int virq)
+{
+clear_bit(virq, d->arch.vgic.allocated_irqs);
+}
+
  struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
unsigned int virq)
  {



--
Julien Grall

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

Re: [Xen-devel] Xen 4.11 Development Update

[Dario Faggioli]

Hey Juergen,

On Wed, 2018-02-28 at 09:23 +0100, Juergen Gross wrote:
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.11 timeline are as followed:
> 
> * Last posting date: March 16th, 2018
> * Hard code freeze: March 30th, 2018
> * RC1: TBD
> * Release: June 1st, 2018
> 
> === x86 === 
> 
> *  Mitigations for Meltdown/CVE-2017-5754
>   -  Jan Beulich
> 
Now that this is done, are we committing to having your speedup series
in 4.11 as well? I think we should.

Maybe it could even be a blocker, considering how big the performance
impact is (and the fact that the series is already there ;-P).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant

[George Dunlap]

On 03/09/2018 04:55 PM, Olaf Hering wrote:
> The point was to document the counter part. Grep -w 1024 is not helpful.

Of course -- your patch certainly makes the codebase better by making
this number set in only one place, and in making it easier to find who
else is depending on this number with grep.

Jan is saying, however, it's not clear why we have such an arbitrary
limit in the first place.  Andy claims it's a remnant from the days when
we were passing a single page rather than an arbitrary array; it also
serves to  make sure the hypercall doesn't run too long.  But if we use
normal hypercall preemption, we don't need to have this limit at all.

 -George

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

Re: [Xen-devel] [PATCH 46/57] ARM: new VGIC: Add event channel IRQ handling

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

The Xen core/arch code relies on two abstracted functions to inject an
event channel IRQ and to query its pending state.
Implement those to query the state of the new VGIC implementation.


The code looks good, but I am wondering why we ever need to call 
vgic_evtchn_irq_pending in local_event_needs_delivery_nomask.


After all, the event channel is an interrupt. So it should already get 
caught by vgic_pending_irq(). If not, then there are no point to wake up 
the vCPU for nothing (it will not get handled). Stefano, do you have 
insight why the current implementation?


Anyway, the code as it is fine so:

Acked-by: Julien Grall 

Cheers,



Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- add locking

  xen/arch/arm/vgic/vgic.c | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 5bbf55da21..0bf257c865 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -698,6 +698,29 @@ void vgic_kick_vcpus(struct domain *d)
  }
  }
  
+void arch_evtchn_inject(struct vcpu *v)

+{
+vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
+}
+
+bool vgic_evtchn_irq_pending(struct vcpu *v)
+{
+struct vgic_irq *irq;
+unsigned long flags;
+bool pending;
+
+/* Does not work for LPIs. */
+ASSERT(!is_lpi(v->domain->arch.evtchn_irq));
+
+irq = vgic_get_irq(v->domain, v, v->domain->arch.evtchn_irq);
+spin_lock_irqsave(>irq_lock, flags);
+pending = irq_is_pending(irq);
+spin_unlock_irqrestore(>irq_lock, flags);
+vgic_put_irq(v->domain, irq);
+
+return pending;
+}
+
  struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
unsigned int virq)
  {



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 12/16] xen/mm: Switch common/memory.c to use typesafe MFN

[Wei Liu]

On Mon, Mar 05, 2018 at 07:41:54AM -0700, Jan Beulich wrote:
> >>> On 05.03.18 at 15:18,  wrote:
> > On 02/03/18 15:34, Jan Beulich wrote:
> > On 21.02.18 at 15:02,  wrote:
> >>> @@ -95,11 +101,18 @@ static unsigned int max_order(const struct domain *d)
> >>>   return min(order, MAX_ORDER + 0U);
> >>>   }
> >>>   
> >>> +/* Helper to copy a typesafe MFN to guest */
> >>> +#define copy_mfn_to_guest(hnd, off, mfn)\
> >>> +({  \
> >>> +xen_pfn_t mfn_ = mfn_x(mfn);\
> >>> +__copy_to_guest_offset(hnd, off, _, 1); \
> >>> +})
> >> 
> >> Hmm, not really nice, but what do you do.
> > 
> > I am open to better suggestion. I wanted to avoid the conversion all 
> > over the code.
> 
> I have no better suggestion, I'm sorry, hence the "but what do
> you do."
> 
> > Also, do you have an opinion on Wei's suggestion:
> > 
> > "What I meant was to make copy_{to,from}_guest* type-safe. I just feel it
> > a bit strange you only created a wrapper for this file. I wonder why.
> > 
> > Note I'm just asking question. That's not necessarily a good idea to
> > turn them all in the end."
> 
> Well, I didn't really understand what he's after (in the context of
> this series) - copy_{to,from}_guest() don't take or return MFNs or
> GFNs.
> 

Fundamentally Julien's patch is to wrap around an existing API for this
one file only. Why is this file special? Why not just make that class of
APIs do what he wants?

But that is going to be intrusive and a bit counter-intuitive.

(In the spirit of unblocking things, I won't insist making such change.)

Wei.

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

Re: [Xen-devel] [PATCH v4 08/16] xen/mm: Drop the parameter mfn from populate_pt_range

[Wei Liu]

On Mon, Mar 05, 2018 at 07:38:36AM -0700, Jan Beulich wrote:
> >>> On 05.03.18 at 15:11,  wrote:
> > On 05/03/18 14:00, Jan Beulich wrote:
> > On 05.03.18 at 14:43,  wrote:
> >>> Anyway, I don't have much knowledge on the x86 to make the modification
> >>> that you suggested. So I am going to revert to _mfn(0) for x86.
> >> 
> >> I'd prefer if you didn't, but well, it'll be one of us to clean it up
> >> then.
> > I can keep as INVALID_MFN. But then either you or Andrew (or anyone x86 
> > folks) would have to provide the patch to skip incrementing invalid MFN 
> > (if I understood correctly your request).
> 
> Sigh - this should go together imo. While wrongly incrementing from
> zero was bad, wrongly wrapping from INVALID_MFN makes things
> worse.
> 

Try this patch?

---8<---
From 8f0024c690c736d17adde0fa765cbbf6fa2846dc Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Fri, 9 Mar 2018 17:20:14 +
Subject: [PATCH] x86/mm: skip incrementing mfn if it is not a valid mfn

The function is called to fill in page table entries in
populate_pt_range. Skip incrementing mfn if it is invalid.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/mm.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9b559448a7..5f5577c7c2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4731,7 +4731,8 @@ int map_pages_to_xen(
 }
 
 virt+= 1UL << L3_PAGETABLE_SHIFT;
-mfn += 1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += 1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
 nr_mfns -= 1UL << (L3_PAGETABLE_SHIFT - PAGE_SHIFT);
 continue;
 }
@@ -4756,7 +4757,8 @@ int map_pages_to_xen(
 if ( i > nr_mfns )
 i = nr_mfns;
 virt+= i << PAGE_SHIFT;
-mfn += i;
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += i;
 nr_mfns -= i;
 continue;
 }
@@ -4824,7 +4826,8 @@ int map_pages_to_xen(
 }
 
 virt+= 1UL << L2_PAGETABLE_SHIFT;
-mfn += 1UL << PAGETABLE_ORDER;
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += 1UL << PAGETABLE_ORDER;
 nr_mfns -= 1UL << PAGETABLE_ORDER;
 }
 else
@@ -4853,7 +4856,8 @@ int map_pages_to_xen(
 if ( i > nr_mfns )
 i = nr_mfns;
 virt+= i << L1_PAGETABLE_SHIFT;
-mfn += i;
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += i;
 nr_mfns -= i;
 goto check_l3;
 }
@@ -4898,7 +4902,8 @@ int map_pages_to_xen(
 }
 
 virt+= 1UL << L1_PAGETABLE_SHIFT;
-mfn += 1UL;
+if ( !mfn_eq(_mfn(mfn), INVALID_MFN) )
+mfn += 1UL;
 nr_mfns -= 1UL;
 
 if ( (flags == PAGE_HYPERVISOR) &&
-- 
2.11.0


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

Re: [Xen-devel] [PATCH 45/57] ARM: new VGIC: Handle hardware mapped IRQs

[Julien Grall]

Hi Andre,

On 05/03/18 16:04, Andre Przywara wrote:

The VGIC supports virtual IRQs to be connected to a hardware IRQ, so
when a guest EOIs the virtual interrupt, it affects the state of that
corresponding interrupt on the hardware side at the same time.
Implement the interface that the Xen arch/core code expects to connect
the virtual and the physical world.

Signed-off-by: Andre Przywara 


Reviewed-by: Julien Grall 

Cheers,


---
Changelog RFC ... v1:
- add ASSERT for hardware mapped IRQs being SPI only
- check h/w IRQ matches before disconnecting

  xen/arch/arm/vgic/vgic.c | 71 
  1 file changed, 71 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 5246d7c2e7..5bbf55da21 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -698,6 +698,77 @@ void vgic_kick_vcpus(struct domain *d)
  }
  }
  
+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,

+  unsigned int virq)
+{
+struct irq_desc *desc = NULL;
+struct vgic_irq *irq = vgic_get_irq(d, v, virq);
+unsigned long flags;
+
+if ( !irq )
+return NULL;
+
+spin_lock_irqsave(>irq_lock, flags);
+if ( irq->hw )
+{
+ASSERT(irq->hwintid >= VGIC_NR_PRIVATE_IRQS);
+desc = irq_to_desc(irq->hwintid);
+}
+spin_unlock_irqrestore(>irq_lock, flags);
+
+vgic_put_irq(d, irq);
+
+return desc;
+}
+
+/*
+ * was:
+ *  int kvm_vgic_map_phys_irq(struct vcpu *vcpu, u32 virt_irq, u32 
phys_irq)
+ *  int kvm_vgic_unmap_phys_irq(struct vcpu *vcpu, unsigned int virt_irq)
+ */
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *vcpu,
+unsigned int virt_irq, struct irq_desc *desc,
+bool connect)
+{
+struct vgic_irq *irq = vgic_get_irq(d, vcpu, virt_irq);
+unsigned long flags;
+int ret = 0;
+
+if ( !irq )
+return -EINVAL;
+
+spin_lock_irqsave(>irq_lock, flags);
+
+if ( connect )  /* assign a mapped IRQ */
+{
+/* The VIRQ should not be already enabled by the guest */
+if ( !irq->hw && !irq->enabled )
+{
+irq->hw = true;
+irq->hwintid = desc->irq;
+}
+else
+ret = -EBUSY;
+}
+else/* remove a mapped IRQ */
+{
+if ( desc && irq->hwintid != desc->irq )
+{
+ret = -EINVAL;
+}
+else
+{
+irq->hw = false;
+irq->hwintid = 0;
+}
+}
+
+spin_unlock_irqrestore(>irq_lock, flags);
+vgic_put_irq(d, irq);
+
+return ret;
+}
+
  static unsigned int translate_irq_type(bool is_level)
  {
  return is_level ? IRQ_TYPE_LEVEL_HIGH : IRQ_TYPE_EDGE_RISING;



--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen-pvdevice: Introduce a simplistic xen-pvdevice save state

[Anthony PERARD]

On Thu, Mar 08, 2018 at 12:52:31PM +, Igor Druzhinin wrote:
> This should help to avoid problems with accessing the device after
> migration/resume without PV drivers. Older systems will acquire
> the new record when migrated which should not change their state for
> worse.
> 
> Signed-off-by: Igor Druzhinin 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 6/7] xen/domain: Pass the full domctl_createdomain struct to create_domain()

[Andrew Cooper]

On 09/03/18 17:00, Jan Beulich wrote:
 On 09.03.18 at 14:18,  wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -426,8 +426,8 @@ static bool emulation_flags_ok(const struct domain *d, 
>> uint32_t emflags)
>>  return true;
>>  }
>>  
>> -int arch_domain_create(struct domain *d, unsigned int domcr_flags,
>> -   struct xen_arch_domainconfig *config)
>> +int arch_domain_create(struct domain *d,
>> +   struct xen_domctl_createdomain *config)
> Is there any reason for this to not be const? There's no write now
> afaics, and I can't imagine you wanting to add one later on.

I originally planned to make them const, but the ARM side passes data
back to the toolstack, and the prototype is (rightfully) common.

>
>> @@ -1632,14 +1634,16 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>  
>>  if ( dom0_pvh )
>>  {
>> -domcr_flags |= XEN_DOMCTL_CDF_hvm_guest |
>> -   ((hvm_funcs.hap_supported && !opt_dom0_shadow) ?
>> - XEN_DOMCTL_CDF_hap : 0);
>> -config.emulation_flags = XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC;
>> +dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm_guest |
>> +   ((hvm_funcs.hap_supported && !opt_dom0_shadow) ?
>> +XEN_DOMCTL_CDF_hap : 0));
>> +
>> +dom0_cfg.config.emulation_flags =
>> +XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC;
> Would you mind making this |= for ease of future changes?

Certainly.

>
> Other than these
> Acked-by: Jan Beulich 
>
> Jan
>


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8b13bca9b81490fc0e42df25d5feb82bbb47833e
baseline version:
 ovmf 5e3719aeaef198f36808a5e53a1f5bb23762e3a5

Last test of basis   120285  2018-03-06 15:23:25 Z3 days
Testing same since   120340  2018-03-08 07:43:06 Z1 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 
  Hao Wu 
  Heyi Guo 
  Jian J Wang 
  Laszlo Ersek 
  Marc-Andr? Lureau 
  Ruiyu Ni 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   5e3719aeae..8b13bca9b8  8b13bca9b81490fc0e42df25d5feb82bbb47833e -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant

[Andrew Cooper]

On 09/03/18 16:49, George Dunlap wrote:
> On 03/09/2018 04:43 PM, Jan Beulich wrote:
> On 09.03.18 at 17:30,  wrote:
>>> On 03/09/2018 04:25 PM, Jan Beulich wrote:
>>> On 09.03.18 at 17:17,  wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -137,6 +137,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t);
>  #define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>  
> +#define XEN_GETPAGEFRAMEINFO3_MAX_SIZE 1024U
 This is an implementation detail; it shouldn't be made part of the
 public interface. If there's a need for user land to know the value,
 and if there's currently no way to query it, that's what you
 would want to add.
>>> But the domctl interface isn't stable, right?  There's no need to make a
>>> flexible backwards-compatible interface between libxc and Xen; sharing a
>>> #define should be fine, as long as there's only one place to change it.
>> Well, strictly speaking this is an option. But I would prefer if we didn't
>> abuse the "is not a stable interface" property, which this changes
>> feels like it would. 
>>
>> Furthermore it hasn't become clear to me why, if this hard coded
>> number is deemed a problem, we don't get rid of it altogether.
>> Domctl-s have long gained the ability to be preemptible - there
>> various examples.
> Yes, making it preemptible and removing the limit is probably a better
> option.

The 1024 limit was from the 32bit days, where there was a single domheap
page allocated as a bounce buffer.

The logic nowadays is trivial to make continuable, and would remove the
fixed arbitrary upper limit.

~Andrew

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

Re: [Xen-devel] [PATCH 6/7] xen/domain: Pass the full domctl_createdomain struct to create_domain()

[Jan Beulich]

>>> On 09.03.18 at 14:18,  wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -426,8 +426,8 @@ static bool emulation_flags_ok(const struct domain *d, 
> uint32_t emflags)
>  return true;
>  }
>  
> -int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> -   struct xen_arch_domainconfig *config)
> +int arch_domain_create(struct domain *d,
> +   struct xen_domctl_createdomain *config)

Is there any reason for this to not be const? There's no write now
afaics, and I can't imagine you wanting to add one later on.

> @@ -1632,14 +1634,16 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  if ( dom0_pvh )
>  {
> -domcr_flags |= XEN_DOMCTL_CDF_hvm_guest |
> -   ((hvm_funcs.hap_supported && !opt_dom0_shadow) ?
> - XEN_DOMCTL_CDF_hap : 0);
> -config.emulation_flags = XEN_X86_EMU_LAPIC|XEN_X86_EMU_IOAPIC;
> +dom0_cfg.flags |= (XEN_DOMCTL_CDF_hvm_guest |
> +   ((hvm_funcs.hap_supported && !opt_dom0_shadow) ?
> +XEN_DOMCTL_CDF_hap : 0));
> +
> +dom0_cfg.config.emulation_flags =
> +XEN_X86_EMU_LAPIC | XEN_X86_EMU_IOAPIC;

Would you mind making this |= for ease of future changes?

Other than these
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC

[Ji, John]

Thanks, George! This includes part of Intel features. Chao is working on a 
complete list of patch series and their status for all Intel features. 


Best Regards

John Ji


-Original Message-
From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of George Dunlap
Sent: Saturday, March 10, 2018 12:01 AM
To: Lars Kurth 
Cc: xen-devel ; committ...@xenproject.org; 
Juergen Gross ; Janakarajan Natarajan ; 
Tamas K Lengyel ; Wei Liu ; Andrew 
Cooper ; Daniel Kiper ; 
Roger Pau Monné ; Christopher Clark 
; Ji, John ; Rich Persaud 
; Paul Durrant ; Jan Beulich' 
; Brian Woods 
Subject: Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC

On Wed, Mar 7, 2018 at 4:26 PM, Lars Kurth  wrote:
>
>
> On 07/03/2018, 17:02, "George Dunlap"  wrote:
>
> >> * Title of series
> >>
> >> * Link to series (e.g. on 
> https://lists.xenproject.org/archives/html/xen-devel,
> >> markmail, …)
> >>
> >> * Number of outstanding ACKs (and by whom), number of ACKs
> >
> >I assume you're suggesting that individuals should reply to this email
> >with that information?  And that to begin with you'll be acting as
> >secretary to keep track of it?
>
> Correct.
>
> Although it is also OK for someone within an organization to do that on 
> behalf of several developers within that organisation.
>
> I will also chair the meeting and write up high-level notes. But for deeply 
> technical discussions, which requires detail: I would prefer if someone else 
> wrote notes for the section and sent them to me afterwards, or replied to the 
> notes I would send out.

OK, well here are some series I have lurking around my inbox that I think 
coordination might need doing for:

* Intel EPT-Based Sub-page Write Protection Support.

marc.info/?i=

RFC posted by Zhang Yi Oct 19, 2017; No acks, reviews only by memaccess 
maintainers / developers.

* Virtual VT-d (vIOMMU)

marc.info/?i=<1506049330-11196-1-git-send-email-tianyu@intel.com>

v3 posted by Lan Tianyu on 22 September 2017.  Seems to have had review by 
Roger Pau Monne (not counted acks).

* Extend resources to support more vcpus in single VM

marc.info/?i=<1505278369-21605-1-git-send-email-tianyu@intel.com>

RFC posted by Lan Tianyu on 13 September 2017.  I have an idea this may have 
been reposted but I dont' thave that link to hand.

* Add guest CPU topology support

marc.info/?i=<1515384090-175916-1-git-send-email-chao@intel.com>

RFC posted by Chao Gao on 1 January 2018.  Some feedback from Andrew Cooper.

* Intel Processor Trace virtulization enabling

marc.info/?i=<1516039953-2988-1-git-send-email-luwei.k...@intel.com>

v1.1 Posted by Lan Tianyu on 15 January 2018.  No feedback.

*  x86: guest resource mapping

marc.info/?i=<20180103121942.3524-1-paul.durr...@citrix.com>

v17 posted by Paul Durrant on 3 January 2018.  Seems to have a fair amount of 
R-b's, but still more feedback.

* paravirtual IOMMU interface

marc.info/?i=<20180212104714.1922-1-paul.durr...@citrix.com>

v1 posted by Paul Durrant on 12 Feb 2018.  Seems to have had a lot of feedback 
from Kevin Tian.

* Add vNVDIMM support to HVM domains

marc.info/?i=<20171207101030.22364-1-haozhong.zh...@intel.com>

RFC posted by Haozhong Zhang on 7 December 2017.  A few messages about the 
overall architecture; some more detailed comments by Anthony on the integration 
with the toolstack.

* x86: emulator enhancements

marc.info/?i=<5a96b3b90278001ac...@prv-mh.provo.novell.com>

v4 posted by Jan Beulich on 28 Feb 2018.  Most patches seem to have acks or 
r-bs, but I know this one has been around a long time, so it might be worth 
making sure we can get it in before the feature freeze.

 -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant

[Olaf Hering]

The point was to document the counter part. Grep -w 1024 is not helpful.

Olaf___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

[Wei Liu]

On Fri, Feb 23, 2018 at 09:03:26PM +0100, Marek Marczykowski-Górecki wrote:
> On Fri, Feb 23, 2018 at 06:47:57PM +, Wei Liu wrote:
> > On Fri, Feb 09, 2018 at 12:14:03AM +0100, Marek Marczykowski-Górecki wrote:
> > > When fd=-1, no savefile will be written, but the domain will still be
> > > suspended (but not destroyed). The main reason for this functionality is
> > > to suspend the host while some domains are running, potentially holding
> > > PCI devices. This will give a chance to a driver in such a domain to
> > > properly suspend device.
> > > 
> > > It would be better to have separate function for this, but in fact it
> > > should be named libxl_domain_suspend, then the current one renamed to
> > > libxl_domain_save. Since that would break API compatibility, keep it in
> > > the same function.
> > > 
> > > Signed-off-by: Marek Marczykowski-Górecki 
> > > 
> > > Signed-off-by: Marcus of Wetware Labs 
> > 
> > The basic idea seems sensible.
> > 
> > Please add a comment to libxl.h to specify the new semantics.
> 
> Hmm, while I'm looking at it, maybe better idea would be to use flags
> for that? I'd call it LIBXL_SUSPEND_SUSPEND, but it looks stupid, any
> better idea?

I don't have any better idea I'm afraid...

Wei.

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

Re: [Xen-devel] [PATCH 5/7] x86/domain: Optimise the order of actions in arch_domain_create()

[Jan Beulich]

>>> On 09.03.18 at 14:18,  wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -430,20 +430,37 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
> struct xen_arch_domainconfig *config)
>  {
>  bool paging_initialised = false;
> +uint32_t emflags;
>  int rc;
>  
> -if ( config == NULL && !is_idle_domain(d) )
> -return -EINVAL;
> -
> -d->arch.s3_integrity = domcr_flags & XEN_DOMCTL_CDF_s3_integrity;
> -
>  INIT_LIST_HEAD(>arch.pdev_list);
>  
>  d->arch.relmem = RELMEM_not_started;
>  INIT_PAGE_LIST_HEAD(>arch.relmem_list);
>  
> -if ( d->domain_id && !is_idle_domain(d) &&
> - cpu_has_amd_erratum(_cpu_data, AMD_ERRATUM_121) )
> +spin_lock_init(>arch.e820_lock);
> +spin_lock_init(>arch.vtsc_lock);
> +
> +/* Minimal initialisation for the idle domain. */
> +if ( unlikely(is_idle_domain(d)) )
> +{
> +static const struct arch_csw idle_csw = {
> +.from = paravirt_ctxt_switch_from,
> +.to   = paravirt_ctxt_switch_to,
> +.tail = continue_idle_domain,
> +};
> +
> +d->arch.ctxt_switch = _csw;
> +
> +d->arch.cpuid = ZERO_BLOCK_PTR; /* Catch stray misuses. */
> +d->arch.msr = ZERO_BLOCK_PTR;
> +
> +return 0;
> +}
> +else if ( !config )

May I suggest to avoid the "else" here? Other than that and with
Wei's R-b
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

[Wei Liu]

On Tue, Jan 16, 2018 at 02:12:27AM +0800, Luwei Kang wrote:
> This patch add a flag to enable Intel PT (Intel processor trace).
> Default value is 1 (enabled).
> 
> Signed-off-by: Luwei Kang 
> ---
>  docs/misc/xen-command-line.markdown |  7 +++
>  xen/arch/x86/cpu/Makefile   |  1 +
>  xen/arch/x86/cpu/intel_pt.c | 27 +++
>  xen/include/asm-x86/intel_pt.h  | 26 ++
>  4 files changed, 61 insertions(+)
>  create mode 100644 xen/arch/x86/cpu/intel_pt.c
>  create mode 100644 xen/include/asm-x86/intel_pt.h
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 781110d..95411cf 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1009,6 +1009,13 @@ debug hypervisor only).
>  ### idle\_latency\_factor
>  > `= `
>  
> +### intel\_pt
> +> `= `
> +
> +> Default: `true`
> +
> +Flag to enable Intel Processor Trace.
> +
>  ### ioapic\_ack
>  > `= old | new`
>  

No document for this option?

> diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
> index 74f23ae..33d7a74 100644
> --- a/xen/arch/x86/cpu/Makefile
> +++ b/xen/arch/x86/cpu/Makefile
> @@ -8,3 +8,4 @@ obj-y += intel.o
>  obj-y += intel_cacheinfo.o
>  obj-y += mwait-idle.o
>  obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
> +obj-y += intel_pt.o

Move this after intel_cacheinfo please.

We order things alphabetically.

> diff --git a/xen/arch/x86/cpu/intel_pt.c b/xen/arch/x86/cpu/intel_pt.c
> new file mode 100644
> index 000..520e0ca
> --- /dev/null
> +++ b/xen/arch/x86/cpu/intel_pt.c
> @@ -0,0 +1,27 @@
> +/*
> + * intel_pt.c: Support Intel Processor Trace Virtualization.
> + *
> + * Copyright (c) 2018, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; If not, see .
> + *
> + * Author: Luwei Kang 
> + */
> +
> +#include 
> +#include 
> +#include 

Please order the headers alphabetically.

> +
> +/* intel_pt: Flag to enable Intel Processor Trace (default on). */
> +bool_t __read_mostly opt_intel_pt = 1;

Use plain bool and true please.

> +boolean_param("intel_pt", opt_intel_pt);
> diff --git a/xen/include/asm-x86/intel_pt.h b/xen/include/asm-x86/intel_pt.h
> new file mode 100644
> index 000..2a8b579
> --- /dev/null
> +++ b/xen/include/asm-x86/intel_pt.h
> @@ -0,0 +1,26 @@
> +/*
> + * intel_pt.h: Intel Processor Trace virtualization for HVM domain.
> + *
> + * Copyright (c) 2018, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; If not, see .
> + *
> + * Author: Luwei Kang 
> + */
> +
> +#ifndef __ASM_X86_HVM_INTEL_PT_H_
> +#define __ASM_X86_HVM_INTEL_PT_H_
> +
> +extern bool_t opt_intel_pt;
> +
> +#endif /* __ASM_X86_HVM_INTEL_PT_H_ */
> -- 
> 1.8.3.1
> 

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

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant

[George Dunlap]

On 03/09/2018 04:43 PM, Jan Beulich wrote:
 On 09.03.18 at 17:30,  wrote:
>> On 03/09/2018 04:25 PM, Jan Beulich wrote:
>> On 09.03.18 at 17:17,  wrote:
 --- a/xen/include/public/domctl.h
 +++ b/xen/include/public/domctl.h
 @@ -137,6 +137,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t);
  #define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
  
 +#define XEN_GETPAGEFRAMEINFO3_MAX_SIZE 1024U
>>>
>>> This is an implementation detail; it shouldn't be made part of the
>>> public interface. If there's a need for user land to know the value,
>>> and if there's currently no way to query it, that's what you
>>> would want to add.
>>
>> But the domctl interface isn't stable, right?  There's no need to make a
>> flexible backwards-compatible interface between libxc and Xen; sharing a
>> #define should be fine, as long as there's only one place to change it.
> 
> Well, strictly speaking this is an option. But I would prefer if we didn't
> abuse the "is not a stable interface" property, which this changes
> feels like it would. 
> 
> Furthermore it hasn't become clear to me why, if this hard coded
> number is deemed a problem, we don't get rid of it altogether.
> Domctl-s have long gained the ability to be preemptible - there
> various examples.

Yes, making it preemptible and removing the limit is probably a better
option.

 -George

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

Re: [Xen-devel] [PATCH 4/7] x86/domain: Remove unused parameters from {hvm, pv}_domain_initialise()

[Jan Beulich]

>>> On 09.03.18 at 15:13,  wrote:
> On Fri, Mar 09, 2018 at 01:18:39PM +, Andrew Cooper wrote:
>> Neither domcr_flags nor config are used on either side.  Drop them, making
>> {hvm,pv}_domain_initialise() symmetric with all the other domain/vcpu
>> initialise/destroy calls.
>> 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 2/7] xen/domain: Drop all DOMCRF_* constants

[Jan Beulich]

>>> On 09.03.18 at 15:16,  wrote:
> Reviewed-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 1/7] xen/domain: Drop DOMCRF_dummy

[Jan Beulich]

>>> On 09.03.18 at 15:12,  wrote:
> On Fri, Mar 09, 2018 at 01:18:36PM +, Andrew Cooper wrote:
>> At the moment, there is a tight coupling between the domid and the use of
>> DOMCRF_dummy.  Instead of using DOMCRF_dummy, base the one relevent decision
>> on domid alone.
>> 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant

[Jan Beulich]

>>> On 09.03.18 at 17:30,  wrote:
> On 03/09/2018 04:25 PM, Jan Beulich wrote:
> On 09.03.18 at 17:17,  wrote:
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -137,6 +137,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t);
>>>  #define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>>>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>>>  
>>> +#define XEN_GETPAGEFRAMEINFO3_MAX_SIZE 1024U
>> 
>> This is an implementation detail; it shouldn't be made part of the
>> public interface. If there's a need for user land to know the value,
>> and if there's currently no way to query it, that's what you
>> would want to add.
> 
> But the domctl interface isn't stable, right?  There's no need to make a
> flexible backwards-compatible interface between libxc and Xen; sharing a
> #define should be fine, as long as there's only one place to change it.

Well, strictly speaking this is an option. But I would prefer if we didn't
abuse the "is not a stable interface" property, which this changes
feels like it would. 

Furthermore it hasn't become clear to me why, if this hard coded
number is deemed a problem, we don't get rid of it altogether.
Domctl-s have long gained the ability to be preemptible - there
various examples.

Jan


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

[Xen-devel] [PATCH 6/6] ARM: GIC: extend LR read/write functions to cover EOI and source

[julien . grall]

From: Andre Przywara 

So far our LR read/write functions do not handle the EOI bit and the
source CPUID bits in an LR, because the current VGIC implementation does
not use them.
Extend the gic_lr data structure to hold these bits of information by
using a union to differentiate field used depending on whether the vIRQ
has a corresponding pIRQ.

Note that source is not covered by GICv3 LR.

This allows the new VGIC to use this information.

Signed-off-by: Andre Przywara 
Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c | 22 +++---
 xen/arch/arm/gic-v3.c | 11 +--
 xen/include/asm-arm/gic.h | 16 ++--
 3 files changed, 42 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index daf8c61258..69f8d6044a 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -474,8 +474,17 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 
 if ( lr_reg->hw_status )
 {
-lr_reg->pirq = lrv >> GICH_V2_LR_PHYSICAL_SHIFT;
-lr_reg->pirq &= GICH_V2_LR_PHYSICAL_MASK;
+lr_reg->h.pirq = lrv >> GICH_V2_LR_PHYSICAL_SHIFT;
+lr_reg->h.pirq &= GICH_V2_LR_PHYSICAL_MASK;
+}
+else
+{
+lr_reg->v.eoi = (lrv & GICH_V2_LR_MAINTENANCE_IRQ) == 
GICH_V2_LR_MAINTENANCE_IRQ;
+/*
+ * This is only valid for SGI, but it does not matter to always
+ * read it as it should be 0 by default.
+ */
+lr_reg->v.source = (lrv >> GICH_V2_LR_CPUID_SHIFT) & 
GICH_V2_LR_CPUID_MASK;
 }
 }
 
@@ -496,7 +505,14 @@ static void gicv2_write_lr(int lr, const struct gic_lr 
*lr_reg)
 if ( lr_reg->hw_status )
 {
 lrv |= GICH_V2_LR_HW;
-lrv |= lr_reg->pirq << GICH_V2_LR_PHYSICAL_SHIFT;
+lrv |= lr_reg->h.pirq << GICH_V2_LR_PHYSICAL_SHIFT;
+}
+else
+{
+if ( lr_reg->v.eoi )
+lrv |= GICH_V2_LR_MAINTENANCE_IRQ;
+if ( lr_reg->virq < NR_GIC_SGI )
+lrv |= (uint32_t)lr_reg->v.source << GICH_V2_LR_CPUID_SHIFT;
 }
 
 writel_gich(lrv, GICH_LR + lr * 4);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index f73d386df1..a855069111 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1014,7 +1014,9 @@ static void gicv3_read_lr(int lr, struct gic_lr *lr_reg)
 lr_reg->hw_status = (lrv & ICH_LR_HW) == ICH_LR_HW;
 
 if ( lr_reg->hw_status )
-lr_reg->pirq = (lrv >> ICH_LR_PHYSICAL_SHIFT) & ICH_LR_PHYSICAL_MASK;
+lr_reg->h.pirq = (lrv >> ICH_LR_PHYSICAL_SHIFT) & ICH_LR_PHYSICAL_MASK;
+else
+lr_reg->v.eoi = (lrv & ICH_LR_MAINTENANCE_IRQ) == 
ICH_LR_MAINTENANCE_IRQ;
 }
 
 static void gicv3_write_lr(int lr_reg, const struct gic_lr *lr)
@@ -1033,7 +1035,12 @@ static void gicv3_write_lr(int lr_reg, const struct 
gic_lr *lr)
 if ( lr->hw_status )
 {
 lrv |= ICH_LR_HW;
-lrv |= (uint64_t)lr->pirq << ICH_LR_PHYSICAL_SHIFT;
+lrv |= (uint64_t)lr->h.pirq << ICH_LR_PHYSICAL_SHIFT;
+}
+else
+{
+if ( lr->v.eoi )
+lrv |= ICH_LR_MAINTENANCE_IRQ;
 }
 
 /*
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 545901b120..4cf5bb385d 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -204,14 +204,26 @@ union gic_state_data {
  * The LR register format is different for GIC HW version
  */
 struct gic_lr {
-   /* Physical IRQ -> Only set when hw_status is set. */
-   uint32_t pirq;
/* Virtual IRQ */
uint32_t virq;
uint8_t priority;
bool active;
bool pending;
bool hw_status;
+   union
+   {
+   /* Only filled when there are a corresponding pIRQ (hw_state = true) */
+   struct
+   {
+   uint32_t pirq;
+   } h;
+   /* Only filled when there are no corresponding pIRQ (hw_state = false) 
*/
+   struct
+   {
+   bool eoi;
+   uint8_t source;  /* GICv2 only */
+   } v;
+   };
 };
 
 enum gic_version {
-- 
2.11.0


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

[Xen-devel] [PATCH 3/6] xen/arm: gic: Use bool instead of uint8_t for the hw_status in gic_lr

[julien . grall]

From: Julien Grall 

hw_status can only be 1 or 0. So convert to a bool.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c | 9 +
 xen/arch/arm/gic-v3.c | 8 +---
 xen/include/asm-arm/gic.h | 2 +-
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index fc105c08b8..23223575a2 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -468,7 +468,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
 lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & 
GICH_V2_LR_PRIORITY_MASK;
 lr_reg->state = (lrv >> GICH_V2_LR_STATE_SHIFT) & 
GICH_V2_LR_STATE_MASK;
-lr_reg->hw_status = (lrv >> GICH_V2_LR_HW_SHIFT) & GICH_V2_LR_HW_MASK;
+lr_reg->hw_status = (lrv & GICH_V2_LR_HW) == GICH_V2_LR_HW;
 }
 
 static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
@@ -480,9 +480,10 @@ static void gicv2_write_lr(int lr, const struct gic_lr 
*lr_reg)
   ((uint32_t)(lr_reg->priority & GICH_V2_LR_PRIORITY_MASK)
   << GICH_V2_LR_PRIORITY_SHIFT) |
   ((uint32_t)(lr_reg->state & GICH_V2_LR_STATE_MASK)
-   << GICH_V2_LR_STATE_SHIFT) |
-  ((uint32_t)(lr_reg->hw_status & GICH_V2_LR_HW_MASK)
-   << GICH_V2_LR_HW_SHIFT));
+   << GICH_V2_LR_STATE_SHIFT) );
+
+if ( lr_reg->hw_status )
+lrv |= GICH_V2_LR_HW;
 
 writel_gich(lrv, GICH_LR + lr * 4);
 }
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 0dfa1a1e08..0711e509a6 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1011,7 +1011,7 @@ static void gicv3_read_lr(int lr, struct gic_lr *lr_reg)
 
 lr_reg->priority  = (lrv >> ICH_LR_PRIORITY_SHIFT) & ICH_LR_PRIORITY_MASK;
 lr_reg->state = (lrv >> ICH_LR_STATE_SHIFT) & ICH_LR_STATE_MASK;
-lr_reg->hw_status = (lrv >> ICH_LR_HW_SHIFT) & ICH_LR_HW_MASK;
+lr_reg->hw_status = (lrv & ICH_LR_HW) == ICH_LR_HW;
 }
 
 static void gicv3_write_lr(int lr_reg, const struct gic_lr *lr)
@@ -1021,8 +1021,10 @@ static void gicv3_write_lr(int lr_reg, const struct 
gic_lr *lr)
 lrv = ( ((u64)(lr->pirq & ICH_LR_PHYSICAL_MASK) << ICH_LR_PHYSICAL_SHIFT)|
 ((u64)(lr->virq & ICH_LR_VIRTUAL_MASK)  << ICH_LR_VIRTUAL_SHIFT) |
 ((u64)(lr->priority & ICH_LR_PRIORITY_MASK) << ICH_LR_PRIORITY_SHIFT)|
-((u64)(lr->state & ICH_LR_STATE_MASK) << ICH_LR_STATE_SHIFT) |
-((u64)(lr->hw_status & ICH_LR_HW_MASK) << ICH_LR_HW_SHIFT) );
+((u64)(lr->state & ICH_LR_STATE_MASK) << ICH_LR_STATE_SHIFT) );
+
+if ( lr->hw_status )
+lrv |= ICH_LR_HW;
 
 /*
  * When the guest is using vGICv3, all the IRQs are Group 1. Group 0
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 1eb08b856e..daec51499c 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -210,7 +210,7 @@ struct gic_lr {
uint32_t virq;
uint8_t priority;
uint8_t state;
-   uint8_t hw_status;
+   bool hw_status;
 };
 
 enum gic_version {
-- 
2.11.0


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

[Xen-devel] [PATCH 4/6] xen/arm: gic: Split the field state in gic_lr in 2 fields active and pending

[julien . grall]

From: Julien Grall 

Mostly making the code nicer to read.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c | 15 +++
 xen/arch/arm/gic-v3.c | 12 +---
 xen/arch/arm/gic-vgic.c   |  6 +++---
 xen/include/asm-arm/gic.h |  3 ++-
 xen/include/asm-arm/gic_v3_defs.h |  2 ++
 5 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 23223575a2..90d8f652d3 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -51,6 +51,8 @@
 #define GICH_V2_LR_PHYSICAL_SHIFT  10
 #define GICH_V2_LR_STATE_MASK  0x3
 #define GICH_V2_LR_STATE_SHIFT 28
+#define GICH_V2_LR_PENDING (1U << 28)
+#define GICH_V2_LR_ACTIVE  (1U << 29)
 #define GICH_V2_LR_PRIORITY_SHIFT  23
 #define GICH_V2_LR_PRIORITY_MASK   0x1f
 #define GICH_V2_LR_HW_SHIFT31
@@ -467,7 +469,8 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & 
GICH_V2_LR_PHYSICAL_MASK;
 lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
 lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & 
GICH_V2_LR_PRIORITY_MASK;
-lr_reg->state = (lrv >> GICH_V2_LR_STATE_SHIFT) & 
GICH_V2_LR_STATE_MASK;
+lr_reg->pending = (lrv & GICH_V2_LR_PENDING) == GICH_V2_LR_PENDING;
+lr_reg->active = (lrv & GICH_V2_LR_ACTIVE) == GICH_V2_LR_ACTIVE;
 lr_reg->hw_status = (lrv & GICH_V2_LR_HW) == GICH_V2_LR_HW;
 }
 
@@ -478,9 +481,13 @@ static void gicv2_write_lr(int lr, const struct gic_lr 
*lr_reg)
 lrv = ( ((lr_reg->pirq & GICH_V2_LR_PHYSICAL_MASK) << 
GICH_V2_LR_PHYSICAL_SHIFT) |
   ((lr_reg->virq & GICH_V2_LR_VIRTUAL_MASK) << 
GICH_V2_LR_VIRTUAL_SHIFT)   |
   ((uint32_t)(lr_reg->priority & GICH_V2_LR_PRIORITY_MASK)
-  << GICH_V2_LR_PRIORITY_SHIFT) |
-  ((uint32_t)(lr_reg->state & GICH_V2_LR_STATE_MASK)
-   << GICH_V2_LR_STATE_SHIFT) );
+  << GICH_V2_LR_PRIORITY_SHIFT) );
+
+if ( lr_reg->active )
+lrv |= GICH_V2_LR_ACTIVE;
+
+if ( lr_reg->pending )
+lrv |= GICH_V2_LR_PENDING;
 
 if ( lr_reg->hw_status )
 lrv |= GICH_V2_LR_HW;
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 0711e509a6..4dbbf0afd2 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1010,7 +1010,8 @@ static void gicv3_read_lr(int lr, struct gic_lr *lr_reg)
 lr_reg->virq = (lrv >> ICH_LR_VIRTUAL_SHIFT) & ICH_LR_VIRTUAL_MASK;
 
 lr_reg->priority  = (lrv >> ICH_LR_PRIORITY_SHIFT) & ICH_LR_PRIORITY_MASK;
-lr_reg->state = (lrv >> ICH_LR_STATE_SHIFT) & ICH_LR_STATE_MASK;
+lr_reg->pending   = (lrv & ICH_LR_STATE_PENDING) == ICH_LR_STATE_PENDING;
+lr_reg->active= (lrv & ICH_LR_STATE_ACTIVE) == ICH_LR_STATE_ACTIVE;
 lr_reg->hw_status = (lrv & ICH_LR_HW) == ICH_LR_HW;
 }
 
@@ -1020,8 +1021,13 @@ static void gicv3_write_lr(int lr_reg, const struct 
gic_lr *lr)
 
 lrv = ( ((u64)(lr->pirq & ICH_LR_PHYSICAL_MASK) << ICH_LR_PHYSICAL_SHIFT)|
 ((u64)(lr->virq & ICH_LR_VIRTUAL_MASK)  << ICH_LR_VIRTUAL_SHIFT) |
-((u64)(lr->priority & ICH_LR_PRIORITY_MASK) << ICH_LR_PRIORITY_SHIFT)|
-((u64)(lr->state & ICH_LR_STATE_MASK) << ICH_LR_STATE_SHIFT) );
+((u64)(lr->priority & ICH_LR_PRIORITY_MASK) << ICH_LR_PRIORITY_SHIFT) 
);
+
+if ( lr->active )
+lrv |= ICH_LR_STATE_ACTIVE;
+
+if ( lr->pending )
+lrv |= ICH_LR_STATE_PENDING;
 
 if ( lr->hw_status )
 lrv |= ICH_LR_HW;
diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index e3cb47e80e..d831b35525 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -189,7 +189,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 return;
 }
 
-if ( lr_val.state & GICH_LR_ACTIVE )
+if ( lr_val.active )
 {
 set_bit(GIC_IRQ_GUEST_ACTIVE, >status);
 if ( test_bit(GIC_IRQ_GUEST_ENABLED, >status) &&
@@ -197,7 +197,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 {
 if ( p->desc == NULL )
 {
-lr_val.state |= GICH_LR_PENDING;
+lr_val.pending = true;
 gic_hw_ops->write_lr(i, _val);
 }
 else
@@ -205,7 +205,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
  irq, v->domain->domain_id, v->vcpu_id, i);
 }
 }
-else if ( lr_val.state & GICH_LR_PENDING )
+else if ( lr_val.pending )
 {
 int q __attribute__ ((unused)) = 
test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
 #ifdef GIC_DEBUG
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index daec51499c..c32861d4fa 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -209,7 +209,8 @@ struct gic_lr 

Re: [Xen-devel] [PATCH v2] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

[Jan Beulich]

>>> On 09.03.18 at 17:23,  wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -415,14 +415,13 @@ long arch_do_domctl(
>  
>  case XEN_DOMCTL_getpageframeinfo3:
>  {
> -unsigned int num = domctl->u.getpageframeinfo3.num;
> +unsigned long num = domctl->u.getpageframeinfo3.num;
>  unsigned int width = has_32bit_shinfo(currd) ? 4 : 8;
>  
>  /* Games to allow this code block to handle a compat guest. */
>  void __user *guest_handle = domctl->u.getpageframeinfo3.array.p;
>  
> -if ( unlikely(num > XEN_GETPAGEFRAMEINFO3_MAX_SIZE) ||
> - unlikely(num != domctl->u.getpageframeinfo3.num) )
> +if ( unlikely(num > XEN_GETPAGEFRAMEINFO3_MAX_SIZE) )

IMO this doesn't improve anything. If you wanted the types to
remain in sync (and document that), you'd need to use typeof().

Jan


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

[Xen-devel] [PATCH 5/6] xen/arm: GIC: Only set pirq in the LR when hw_status is set

[julien . grall]

From: Julien Grall 

The field pirq should only be valid when the virtual interrupt
is associated to a physical interrupt.

This change will help to extend gic_lr for supporting specific virtual
interrupt field (e.g eoi, source) that clashes with the PIRQ field.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c | 13 ++---
 xen/arch/arm/gic-v3.c | 10 +++---
 xen/include/asm-arm/gic.h |  2 +-
 3 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 90d8f652d3..daf8c61258 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -466,20 +466,24 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 uint32_t lrv;
 
 lrv  = readl_gich(GICH_LR + lr * 4);
-lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & 
GICH_V2_LR_PHYSICAL_MASK;
 lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
 lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & 
GICH_V2_LR_PRIORITY_MASK;
 lr_reg->pending = (lrv & GICH_V2_LR_PENDING) == GICH_V2_LR_PENDING;
 lr_reg->active = (lrv & GICH_V2_LR_ACTIVE) == GICH_V2_LR_ACTIVE;
 lr_reg->hw_status = (lrv & GICH_V2_LR_HW) == GICH_V2_LR_HW;
+
+if ( lr_reg->hw_status )
+{
+lr_reg->pirq = lrv >> GICH_V2_LR_PHYSICAL_SHIFT;
+lr_reg->pirq &= GICH_V2_LR_PHYSICAL_MASK;
+}
 }
 
 static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
 {
 uint32_t lrv = 0;
 
-lrv = ( ((lr_reg->pirq & GICH_V2_LR_PHYSICAL_MASK) << 
GICH_V2_LR_PHYSICAL_SHIFT) |
-  ((lr_reg->virq & GICH_V2_LR_VIRTUAL_MASK) << 
GICH_V2_LR_VIRTUAL_SHIFT)   |
+lrv = (((lr_reg->virq & GICH_V2_LR_VIRTUAL_MASK) << 
GICH_V2_LR_VIRTUAL_SHIFT)   |
   ((uint32_t)(lr_reg->priority & GICH_V2_LR_PRIORITY_MASK)
   << GICH_V2_LR_PRIORITY_SHIFT) );
 
@@ -490,7 +494,10 @@ static void gicv2_write_lr(int lr, const struct gic_lr 
*lr_reg)
 lrv |= GICH_V2_LR_PENDING;
 
 if ( lr_reg->hw_status )
+{
 lrv |= GICH_V2_LR_HW;
+lrv |= lr_reg->pirq << GICH_V2_LR_PHYSICAL_SHIFT;
+}
 
 writel_gich(lrv, GICH_LR + lr * 4);
 }
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 4dbbf0afd2..f73d386df1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1006,21 +1006,22 @@ static void gicv3_read_lr(int lr, struct gic_lr *lr_reg)
 
 lrv = gicv3_ich_read_lr(lr);
 
-lr_reg->pirq = (lrv >> ICH_LR_PHYSICAL_SHIFT) & ICH_LR_PHYSICAL_MASK;
 lr_reg->virq = (lrv >> ICH_LR_VIRTUAL_SHIFT) & ICH_LR_VIRTUAL_MASK;
 
 lr_reg->priority  = (lrv >> ICH_LR_PRIORITY_SHIFT) & ICH_LR_PRIORITY_MASK;
 lr_reg->pending   = (lrv & ICH_LR_STATE_PENDING) == ICH_LR_STATE_PENDING;
 lr_reg->active= (lrv & ICH_LR_STATE_ACTIVE) == ICH_LR_STATE_ACTIVE;
 lr_reg->hw_status = (lrv & ICH_LR_HW) == ICH_LR_HW;
+
+if ( lr_reg->hw_status )
+lr_reg->pirq = (lrv >> ICH_LR_PHYSICAL_SHIFT) & ICH_LR_PHYSICAL_MASK;
 }
 
 static void gicv3_write_lr(int lr_reg, const struct gic_lr *lr)
 {
 uint64_t lrv = 0;
 
-lrv = ( ((u64)(lr->pirq & ICH_LR_PHYSICAL_MASK) << ICH_LR_PHYSICAL_SHIFT)|
-((u64)(lr->virq & ICH_LR_VIRTUAL_MASK)  << ICH_LR_VIRTUAL_SHIFT) |
+lrv = ( ((u64)(lr->virq & ICH_LR_VIRTUAL_MASK)  << ICH_LR_VIRTUAL_SHIFT) |
 ((u64)(lr->priority & ICH_LR_PRIORITY_MASK) << ICH_LR_PRIORITY_SHIFT) 
);
 
 if ( lr->active )
@@ -1030,7 +1031,10 @@ static void gicv3_write_lr(int lr_reg, const struct 
gic_lr *lr)
 lrv |= ICH_LR_STATE_PENDING;
 
 if ( lr->hw_status )
+{
 lrv |= ICH_LR_HW;
+lrv |= (uint64_t)lr->pirq << ICH_LR_PHYSICAL_SHIFT;
+}
 
 /*
  * When the guest is using vGICv3, all the IRQs are Group 1. Group 0
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index c32861d4fa..545901b120 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -204,7 +204,7 @@ union gic_state_data {
  * The LR register format is different for GIC HW version
  */
 struct gic_lr {
-   /* Physical IRQ */
+   /* Physical IRQ -> Only set when hw_status is set. */
uint32_t pirq;
/* Virtual IRQ */
uint32_t virq;
-- 
2.11.0


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

[Xen-devel] [PATCH 0/6] xen/arm: Rework the way to store the LR

[julien . grall]

From: Julien Grall 

Hi all,

This series is meant to replace patch #21 "ARM: GICv2: extend LR read/write
functions to cover EOI and source" from Andre's vGIC series (see [1]).

It has some more clean-up to address potential shortcomings with the interface.

The series is based on "ARM: vGIC: prepare for splitting the vGIC code" [2].

Cheers,

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg00435.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg00950.html

Andre Przywara (1):
  ARM: GIC: extend LR read/write functions to cover EOI and source

Julien Grall (5):
  xen/arm: gic: Fix indentation in gic_update_one_lr
  xen/arm: vgic: Override the group in lr everytime
  xen/arm: gic: Use bool instead of uint8_t for the hw_status in gic_lr
  xen/arm: gic: Split the field state in gic_lr in 2 fields active and
pending
  xen/arm: GIC: Only set pirq in the LR when hw_status is set

 xen/arch/arm/gic-v2.c | 53 ++-
 xen/arch/arm/gic-v3.c | 44 
 xen/arch/arm/gic-vgic.c   |  8 +++---
 xen/include/asm-arm/gic.h | 22 
 xen/include/asm-arm/gic_v3_defs.h |  2 ++
 5 files changed, 98 insertions(+), 31 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH 1/6] xen/arm: gic: Fix indentation in gic_update_one_lr

[julien . grall]

From: Julien Grall 

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-vgic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 61f093db50..e3cb47e80e 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -197,8 +197,8 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 {
 if ( p->desc == NULL )
 {
- lr_val.state |= GICH_LR_PENDING;
- gic_hw_ops->write_lr(i, _val);
+lr_val.state |= GICH_LR_PENDING;
+gic_hw_ops->write_lr(i, _val);
 }
 else
 gdprintk(XENLOG_WARNING, "unable to inject hw irq=%d into 
d%dv%d: already active in LR%d\n",
-- 
2.11.0


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

[Xen-devel] [PATCH 2/6] xen/arm: vgic: Override the group in lr everytime

[julien . grall]

From: Julien Grall 

At the moment, write_lr is assuming the caller will set correctly the
group. However the group should always be 0 when the guest is using
vGICv2 and 1 for vGICv3. As the caller should not care about the group,
override it directly.

With that change, write_lr is now behaving like update_lr for the group.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c |  4 +---
 xen/arch/arm/gic-v3.c | 11 ---
 xen/include/asm-arm/gic.h |  1 -
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index f16e17c1a3..fc105c08b8 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -469,7 +469,6 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & 
GICH_V2_LR_PRIORITY_MASK;
 lr_reg->state = (lrv >> GICH_V2_LR_STATE_SHIFT) & 
GICH_V2_LR_STATE_MASK;
 lr_reg->hw_status = (lrv >> GICH_V2_LR_HW_SHIFT) & GICH_V2_LR_HW_MASK;
-lr_reg->grp   = (lrv >> GICH_V2_LR_GRP_SHIFT) & GICH_V2_LR_GRP_MASK;
 }
 
 static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
@@ -483,8 +482,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr 
*lr_reg)
   ((uint32_t)(lr_reg->state & GICH_V2_LR_STATE_MASK)
<< GICH_V2_LR_STATE_SHIFT) |
   ((uint32_t)(lr_reg->hw_status & GICH_V2_LR_HW_MASK)
-   << GICH_V2_LR_HW_SHIFT)  |
-  ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << 
GICH_V2_LR_GRP_SHIFT) );
+   << GICH_V2_LR_HW_SHIFT));
 
 writel_gich(lrv, GICH_LR + lr * 4);
 }
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 09b49a07d5..0dfa1a1e08 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1012,7 +1012,6 @@ static void gicv3_read_lr(int lr, struct gic_lr *lr_reg)
 lr_reg->priority  = (lrv >> ICH_LR_PRIORITY_SHIFT) & ICH_LR_PRIORITY_MASK;
 lr_reg->state = (lrv >> ICH_LR_STATE_SHIFT) & ICH_LR_STATE_MASK;
 lr_reg->hw_status = (lrv >> ICH_LR_HW_SHIFT) & ICH_LR_HW_MASK;
-lr_reg->grp   = (lrv >> ICH_LR_GRP_SHIFT) & ICH_LR_GRP_MASK;
 }
 
 static void gicv3_write_lr(int lr_reg, const struct gic_lr *lr)
@@ -1023,8 +1022,14 @@ static void gicv3_write_lr(int lr_reg, const struct 
gic_lr *lr)
 ((u64)(lr->virq & ICH_LR_VIRTUAL_MASK)  << ICH_LR_VIRTUAL_SHIFT) |
 ((u64)(lr->priority & ICH_LR_PRIORITY_MASK) << ICH_LR_PRIORITY_SHIFT)|
 ((u64)(lr->state & ICH_LR_STATE_MASK) << ICH_LR_STATE_SHIFT) |
-((u64)(lr->hw_status & ICH_LR_HW_MASK) << ICH_LR_HW_SHIFT)  |
-((u64)(lr->grp & ICH_LR_GRP_MASK) << ICH_LR_GRP_SHIFT) );
+((u64)(lr->hw_status & ICH_LR_HW_MASK) << ICH_LR_HW_SHIFT) );
+
+/*
+ * When the guest is using vGICv3, all the IRQs are Group 1. Group 0
+ * would result in a FIQ, which will not be expected by the guest OS.
+ */
+if ( current->domain->arch.vgic.version == GIC_V3 )
+lrv |= ICH_LR_GRP1;
 
 gicv3_ich_write_lr(lr_reg, lrv);
 }
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 49cb94f792..1eb08b856e 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -211,7 +211,6 @@ struct gic_lr {
uint8_t priority;
uint8_t state;
uint8_t hw_status;
-   uint8_t grp;
 };
 
 enum gic_version {
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant

[George Dunlap]

On 03/09/2018 04:25 PM, Jan Beulich wrote:
 On 09.03.18 at 17:17,  wrote:
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -137,6 +137,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t);
>>  #define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>>  
>> +#define XEN_GETPAGEFRAMEINFO3_MAX_SIZE 1024U
> 
> This is an implementation detail; it shouldn't be made part of the
> public interface. If there's a need for user land to know the value,
> and if there's currently no way to query it, that's what you
> would want to add.

But the domctl interface isn't stable, right?  There's no need to make a
flexible backwards-compatible interface between libxc and Xen; sharing a
#define should be fine, as long as there's only one place to change it.

 -George

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

[Xen-devel] [xen-unstable-smoke test] 120370: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ca8c67629a509f45e83ebdb0f679b692707ad7d9
baseline version:
 xen  5175ce39d8ff0b36e981a7a261f9196aa1879918

Last test of basis   120354  2018-03-08 19:01:23 Z0 days
Testing same since   120370  2018-03-09 14:01:12 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   5175ce39d8..ca8c67629a  ca8c67629a509f45e83ebdb0f679b692707ad7d9 -> smoke

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

Re: [Xen-devel] [PATCH v1] getpageframeinfo3: replace hardcoded batchsize with constant

[Jan Beulich]

>>> On 09.03.18 at 17:17,  wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -137,6 +137,8 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_getdomaininfo_t);
>  #define XEN_DOMCTL_PFINFO_BROKEN  (0xdU<<28) /* broken page */
>  #define XEN_DOMCTL_PFINFO_LTAB_MASK (0xfU<<28)
>  
> +#define XEN_GETPAGEFRAMEINFO3_MAX_SIZE 1024U

This is an implementation detail; it shouldn't be made part of the
public interface. If there's a need for user land to know the value,
and if there's currently no way to query it, that's what you
would want to add.

Jan


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

[Xen-devel] [PATCH v2] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

[Olaf Hering]

The value of num is always the same as domctl->u.getpageframeinfo3.num,
it was assigned just a few lines before. Avoid truncation by making
num the same size as i, which is the only place where num is used.

Signed-off-by: Olaf Hering 
---
 xen/arch/x86/domctl.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index daf733de4f..5d979e3a0f 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -415,14 +415,13 @@ long arch_do_domctl(
 
 case XEN_DOMCTL_getpageframeinfo3:
 {
-unsigned int num = domctl->u.getpageframeinfo3.num;
+unsigned long num = domctl->u.getpageframeinfo3.num;
 unsigned int width = has_32bit_shinfo(currd) ? 4 : 8;
 
 /* Games to allow this code block to handle a compat guest. */
 void __user *guest_handle = domctl->u.getpageframeinfo3.array.p;
 
-if ( unlikely(num > XEN_GETPAGEFRAMEINFO3_MAX_SIZE) ||
- unlikely(num != domctl->u.getpageframeinfo3.num) )
+if ( unlikely(num > XEN_GETPAGEFRAMEINFO3_MAX_SIZE) )
 {
 ret = -E2BIG;
 break;

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

Re: [Xen-devel] [PATCH v6.1 00/11] xen: xen-domid-restrict improvements

[Ian Jackson]

I have folded in the comments so far and made a prototype v7 series,
which is here:

  http://xenbits.xen.org/gitweb/?p=people/iwj/qemu.git;a=summary
  https://xenbits.xen.org/git-http/people/iwj/qemu.git
  git://xenbits.xen.org/people/iwj/qemu.git

In the branch

  master..xen-restrict-v7.0

I have NOT been able to test it, unfortunately, as my test setup for
this had rotted and I am now going away for two weeks.  It does
compile.

I'm posting this here just because it seems bad form to go away with
the branch in a "secret" location on my workstation.  If someone else
wants to pick it up and shepherd it into the 2.12 release then that
would of course be fine by me; if not I will pick it up when I get
back.

I have some more work to build on top of this anyway, including wiring
this into the Xen CI, before it can be declared properly supported by
Xen.

In the meantime maybe the fixes to get_maintainer and checkpatch are
independent of the rest and should probably be applied as soon as
practical (subject to any further review that may be needed).  that
is:

 [PATCH 01/12] checkpatch: Add xendevicemodel_handle to the list of types
 [PATCH 12/12] scripts/get_maintainer.pl: Print proper error message for 
missing $file

Or from my branch above,

 cb3ebff4087a checkpatch: Add xendevicemodel_handle to the list of types
 15dedc627cad scripts/get_maintainer.pl: Print proper error message for missing 
$file

Regards,
Ian.

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

Re: [Xen-devel] [PATCH 10/12] xen: Use newly added dmops for mapping VGA memory

[Ian Jackson]

Ian Jackson writes ("Re: [PATCH 10/12] xen: Use newly added dmops for mapping 
VGA memory"):
> Anthony PERARD writes ("Re: [PATCH 10/12] xen: Use newly added dmops for 
> mapping VGA memory"):
> > This patch seems to remove the last users of
> > xen_xc_domain_add_to_physmap(). Can it be remove from xen_common.h?
> > 
> > With that:
> > Acked-by: Anthony PERARD 
> 
> Have added a separate patch for that.

Wrong patch.  Gah!

From 8794b90b82612665d1e3f9f96ab73579a271c3be Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Fri, 9 Mar 2018 16:08:55 +
Subject: [PATCH 3/5] xen: Remove now-obsolete xen_xc_domain_add_to_physmap

The last user was just removed; remove this function, accordingly.

Signed-off-by: Ian Jackson 
---
 include/hw/xen/xen_common.h | 22 --
 1 file changed, 22 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 2eed6fc..5f1402b 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -645,28 +645,6 @@ static inline int xen_set_ioreq_server_state(domid_t dom,
 
 #endif
 
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40600
-static inline int xen_xc_domain_add_to_physmap(xc_interface *xch, uint32_t 
domid,
-   unsigned int space,
-   unsigned long idx,
-   xen_pfn_t gpfn)
-{
-return xc_domain_add_to_physmap(xch, domid, space, idx, gpfn);
-}
-#else
-static inline int xen_xc_domain_add_to_physmap(xc_interface *xch, uint32_t 
domid,
-   unsigned int space,
-   unsigned long idx,
-   xen_pfn_t gpfn)
-{
-/* In Xen 4.6 rc is -1 and errno contains the error value. */
-int rc = xc_domain_add_to_physmap(xch, domid, space, idx, gpfn);
-if (rc == -1)
-return errno;
-return rc;
-}
-#endif
-
 #ifdef CONFIG_XEN_PV_DOMAIN_BUILD
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40700
 static inline int xen_domain_create(xc_interface *xc, uint32_t ssidref,
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] tools/xenstore: add libdl dependency to libxenstore

[Wei Liu]

On Fri, Mar 09, 2018 at 12:08:42PM +0100, Olaf Hering wrote:
> On Fri, Mar 09, Olaf Hering wrote:
> 
> > abuild@latitude:~> readelf -Wa /usr/lib64/libpython2.7.so | grep dlsym
> > 003e5e08  00d90007 R_X86_64_JUMP_SLOT  
> > dlsym@GLIBC_2.2.5 + 0
> >217:  0 FUNCGLOBAL DEFAULT  UND 
> > dlsym@GLIBC_2.2.5 (10)
> > abuild@latitude:~> readelf -Wa /usr/lib64/libxenstore.so | grep dlsym
> > 002071b0  002b0007 R_X86_64_JUMP_SLOT  
> > dlsym + 0
> > 43:  0 NOTYPE  GLOBAL DEFAULT  UND dlsym
> 
> The difference is SUSE_ASNEEDED=1 in environment.
> If it is set, libxenstore.so will not link to libdl.so.
> If it is not, libxenstore.so will link to libdl.so.
> Since package building exports SUSE_ASNEEDED=1 usage of -lxenstore will
> fail. Not sure how all the other packages use dlsym(), clearly xenstore
> does something different.

I'm not sure what to make of this. I'm not sure what SUSE_ASNEEDED is
for. I guess I will leave this to you SuSE experts to sort out. :-)

Wei.

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

Re: [Xen-devel] [PATCH 10/12] xen: Use newly added dmops for mapping VGA memory

[Ian Jackson]

Anthony PERARD writes ("Re: [PATCH 10/12] xen: Use newly added dmops for 
mapping VGA memory"):
> This patch seems to remove the last users of
> xen_xc_domain_add_to_physmap(). Can it be remove from xen_common.h?
> 
> With that:
> Acked-by: Anthony PERARD 

Have added a separate patch for that.

From 15dedc627cad96301e4015f1f777fcab3906aba7 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Fri, 27 Oct 2017 11:23:10 +0100
Subject: [PATCH 5/5] scripts/get_maintainer.pl: Print proper error message for
 missing $file

If you pass scripts/get_maintainer.pl the name of a FIFO or other
exciting object (/dev/stdin, for example), it would falsely print
"file not found".  Instead: stat the object rather than using -f so
that we do not mind if the object is not a file; and print the errno
value in the error message.

Signed-off-by: Ian Jackson 
CC: Thomas Huth 
CC: Paolo Bonzini 
CC: Stefano Stabellini 
CC: Anthony PERARD 
---
v6: New patch in this version of the series
---
 scripts/get_maintainer.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 07369aa..43fb5f5 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -381,8 +381,8 @@ foreach my $file (@ARGV) {
##if $file is a directory and it lacks a trailing slash, add one
if ((-d $file)) {
$file =~ s@([^/])$@$1/@;
-   } elsif (!(-f $file)) {
-   die "$P: file '${file}' not found\n";
+   } elsif (!(stat $file)) {
+   die "$P: file '${file}' not found: $!\n";
}
 }
 if ($from_filename) {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v1] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

[Olaf Hering]

On Fri, Mar 09, Andrew Cooper wrote:

> On 09/03/18 16:01, Olaf Hering wrote:
> > The value of num is always the same as domctl->u.getpageframeinfo3.num,
> > it was assigned just a few lines before.
> >
> > Signed-off-by: Olaf Hering 
> 
> This isn't dead code.  It is a truncation check.

How can this happen, other than num being a 32bit type?
Perhaps the type of num should match the type of i?

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

[Wei Liu]

On Fri, Mar 09, 2018 at 05:01:16PM +0100, Olaf Hering wrote:
> The value of num is always the same as domctl->u.getpageframeinfo3.num,
> it was assigned just a few lines before.
> 
> Signed-off-by: Olaf Hering 

It is still useful.  The field in getpageframeinfo3 is uint64_aligned_t
while here num is just unsigned int. The check makes sure no truncation
happens.

> ---
>  xen/arch/x86/domctl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 8fbbf3aeb3..46d288a490 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -421,8 +421,7 @@ long arch_do_domctl(
>  /* Games to allow this code block to handle a compat guest. */
>  void __user *guest_handle = domctl->u.getpageframeinfo3.array.p;
>  
> -if ( unlikely(num > 1024) ||
> - unlikely(num != domctl->u.getpageframeinfo3.num) )
> +if ( unlikely(num > 1024) )
>  {
>  ret = -E2BIG;
>  break;
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [PATCH v1] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

[Andrew Cooper]

On 09/03/18 16:01, Olaf Hering wrote:
> The value of num is always the same as domctl->u.getpageframeinfo3.num,
> it was assigned just a few lines before.
>
> Signed-off-by: Olaf Hering 

This isn't dead code.  It is a truncation check.

~Andrew

> ---
>  xen/arch/x86/domctl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 8fbbf3aeb3..46d288a490 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -421,8 +421,7 @@ long arch_do_domctl(
>  /* Games to allow this code block to handle a compat guest. */
>  void __user *guest_handle = domctl->u.getpageframeinfo3.array.p;
>  
> -if ( unlikely(num > 1024) ||
> - unlikely(num != domctl->u.getpageframeinfo3.num) )
> +if ( unlikely(num > 1024) )
>  {
>  ret = -E2BIG;
>  break;


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

Re: [Xen-devel] osstest planned outage consultation

[Ian Jackson]

Ian Jackson writes ("Re: osstest planned outage consultation"):
> It turns out that another key member of staff is away then.  We will
> have to do this some time in late April.  Some time the [week] of the
> 16th-20th I think.

Lars, can you check this is OK with Credativ and then report back here
with a confirmation we're doing it then ?

Ian.

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

[Xen-devel] [PATCH v1] x86/domctl: remove impossible condition in XEN_DOMCTL_getpageframeinfo3

[Olaf Hering]

The value of num is always the same as domctl->u.getpageframeinfo3.num,
it was assigned just a few lines before.

Signed-off-by: Olaf Hering 
---
 xen/arch/x86/domctl.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 8fbbf3aeb3..46d288a490 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -421,8 +421,7 @@ long arch_do_domctl(
 /* Games to allow this code block to handle a compat guest. */
 void __user *guest_handle = domctl->u.getpageframeinfo3.array.p;
 
-if ( unlikely(num > 1024) ||
- unlikely(num != domctl->u.getpageframeinfo3.num) )
+if ( unlikely(num > 1024) )
 {
 ret = -E2BIG;
 break;

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

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC

[George Dunlap]

On Wed, Mar 7, 2018 at 4:26 PM, Lars Kurth  wrote:
>
>
> On 07/03/2018, 17:02, "George Dunlap"  wrote:
>
> >> * Title of series
> >>
> >> * Link to series (e.g. on 
> https://lists.xenproject.org/archives/html/xen-devel,
> >> markmail, …)
> >>
> >> * Number of outstanding ACKs (and by whom), number of ACKs
> >
> >I assume you're suggesting that individuals should reply to this email
> >with that information?  And that to begin with you'll be acting as
> >secretary to keep track of it?
>
> Correct.
>
> Although it is also OK for someone within an organization to do that on 
> behalf of several developers within that organisation.
>
> I will also chair the meeting and write up high-level notes. But for deeply 
> technical discussions, which requires detail: I would prefer if someone else 
> wrote notes for the section and sent them to me afterwards, or replied to the 
> notes I would send out.

OK, well here are some series I have lurking around my inbox that I
think coordination might need doing for:

* Intel EPT-Based Sub-page Write Protection Support.

marc.info/?i=

RFC posted by Zhang Yi Oct 19, 2017; No acks, reviews only by
memaccess maintainers / developers.

* Virtual VT-d (vIOMMU)

marc.info/?i=<1506049330-11196-1-git-send-email-tianyu@intel.com>

v3 posted by Lan Tianyu on 22 September 2017.  Seems to have had
review by Roger Pau Monne (not counted acks).

* Extend resources to support more vcpus in single VM

marc.info/?i=<1505278369-21605-1-git-send-email-tianyu@intel.com>

RFC posted by Lan Tianyu on 13 September 2017.  I have an idea this
may have been reposted but I dont' thave that link to hand.

* Add guest CPU topology support

marc.info/?i=<1515384090-175916-1-git-send-email-chao@intel.com>

RFC posted by Chao Gao on 1 January 2018.  Some feedback from Andrew Cooper.

* Intel Processor Trace virtulization enabling

marc.info/?i=<1516039953-2988-1-git-send-email-luwei.k...@intel.com>

v1.1 Posted by Lan Tianyu on 15 January 2018.  No feedback.

*  x86: guest resource mapping

marc.info/?i=<20180103121942.3524-1-paul.durr...@citrix.com>

v17 posted by Paul Durrant on 3 January 2018.  Seems to have a fair
amount of R-b's, but still more feedback.

* paravirtual IOMMU interface

marc.info/?i=<20180212104714.1922-1-paul.durr...@citrix.com>

v1 posted by Paul Durrant on 12 Feb 2018.  Seems to have had a lot of
feedback from Kevin Tian.

* Add vNVDIMM support to HVM domains

marc.info/?i=<20171207101030.22364-1-haozhong.zh...@intel.com>

RFC posted by Haozhong Zhang on 7 December 2017.  A few messages about
the overall architecture; some more detailed comments by Anthony on
the integration with the toolstack.

* x86: emulator enhancements

marc.info/?i=<5a96b3b90278001ac...@prv-mh.provo.novell.com>

v4 posted by Jan Beulich on 28 Feb 2018.  Most patches seem to have
acks or r-bs, but I know this one has been around a long time, so it
might be worth making sure we can get it in before the feature freeze.

 -George

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

Re: [Xen-devel] [PATCH 11/12] xen: Expect xenstore write to fail when restricted

[Anthony PERARD]

On Thu, Mar 08, 2018 at 07:03:06PM +, Ian Jackson wrote:
> From: Ross Lagerwall 
> 
> Saving the current state to xenstore may fail when running restricted
> (in particular, after a migration). Therefore, don't report the error or
> exit when running restricted.  Toolstacks that want to allow running
> QEMU restricted should instead make use of QMP events to listen for
> state changes.
> 
> CC: Ian Jackson 
> Signed-off-by: Ross Lagerwall 
> Reviewed-by: Ian Jackson 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 10/12] xen: Use newly added dmops for mapping VGA memory

[Anthony PERARD]

On Thu, Mar 08, 2018 at 07:03:05PM +, Ian Jackson wrote:
> From: Ross Lagerwall 
> 
> Xen unstable (to be in 4.11) has two new dmops, relocate_memory and
> pin_memory_cacheattr. Use these to set up the VGA memory, replacing the
> previous calls to libxc. This allows the VGA console to work properly
> when QEMU is running restricted (-xen-domid-restrict).
> 
> Wrapper functions are provided to allow QEMU to work with older versions
> of Xen.
> 
> Tweak the error handling while making this change:
> * Report pin_memory_cacheattr errors.
> * Report errors even when DEBUG_HVM is not set. This is useful for
> trying to understand why VGA is not working, since otherwise it just
> fails silently.
> * Fix the return values when an error occurs. The functions now
> consistently return -1 and set errno.
> 
> CC: Ian Jackson 
> Signed-off-by: Ross Lagerwall 
> Reviewed-by: Ian Jackson 
> Signed-off-by: Ian Jackson 
> ---
> v6.1: Fix printf formats to match types in error_report messages
>   Fix spurious \n in error_report messages
>   Fix { } style issue
> v6: New patch in this version of the series
> ---
>  configure   | 19 +
>  hw/i386/xen/xen-hvm.c   | 50 
> -
>  include/hw/xen/xen_common.h | 32 +
>  3 files changed, 78 insertions(+), 23 deletions(-)
> 
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index fb727bc..caa563b 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -347,7 +347,7 @@ static int xen_add_to_physmap(XenIOState *state,
>MemoryRegion *mr,
>hwaddr offset_within_region)
>  {
> -unsigned long i = 0;
> +unsigned long nr_pages;
>  int rc = 0;
>  XenPhysmap *physmap = NULL;
>  hwaddr pfn, start_gpfn;
> @@ -396,22 +396,26 @@ go_physmap:
>  
>  pfn = phys_offset >> TARGET_PAGE_BITS;
>  start_gpfn = start_addr >> TARGET_PAGE_BITS;
> -for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
> -unsigned long idx = pfn + i;
> -xen_pfn_t gpfn = start_gpfn + i;
> -
> -rc = xen_xc_domain_add_to_physmap(xen_xc, xen_domid, 
> XENMAPSPACE_gmfn, idx, gpfn);

This patch seems to remove the last users of
xen_xc_domain_add_to_physmap(). Can it be remove from xen_common.h?

With that:
Acked-by: Anthony PERARD 

Thanks.

> -if (rc) {
> -DPRINTF("add_to_physmap MFN %"PRI_xen_pfn" to PFN %"
> -PRI_xen_pfn" failed: %d (errno: %d)\n", idx, gpfn, rc, 
> errno);
> -return -rc;
> -}
> +nr_pages = size >> TARGET_PAGE_BITS;
> +rc = xendevicemodel_relocate_memory(xen_dmod, xen_domid, nr_pages, pfn,
> +start_gpfn);
> +if (rc) {
> +int saved_errno = errno;
> +
> +error_report("relocate_memory %lu pages from GFN %"HWADDR_PRIx
> + " to GFN %"HWADDR_PRIx" failed: %s",
> + nr_pages, pfn, start_gpfn, strerror(saved_errno));
> +errno = saved_errno;
> +return -1;
>  }
>  


-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH] cpufreq/ondemand: fix race while offlining CPU

[Wei Liu]

On Fri, Mar 09, 2018 at 02:34:32AM -0700, Jan Beulich wrote:
> Offlining a CPU involves stopping the cpufreq governor. The on-demand
> governor will kill the timer before letting generic code proceed, but
> since that generally isn't happening on the subject CPU,
> cpufreq_dbs_timer_resume() may run in parallel. If that managed to
> invoke the timer handler, that handler needs to run to completion before
> dbs_timer_exit() may safely exit.
> 
> Make the "stoppable" field a tristate, changing it from +1 to -1 around
> the timer function invocation, and make dbs_timer_exit() wait for it to
> become non-negative (still writing zero if it's +1).
> 
> Also adjust coding style in cpufreq_dbs_timer_resume().
> 
> Reported-by: Martin Cerveny 
> Signed-off-by: Jan Beulich 
> Tested-by: Martin Cerveny 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86/traps: Put idt_table[] back into .bss

[Wei Liu]

On Fri, Mar 09, 2018 at 03:03:47PM +, Andrew Cooper wrote:
> c/s d1d6fc97d "x86/xpti: really hide almost all of Xen image" accidentially
> moved idt_table[] from .bss to .data by virtue of using the page_aligned
> section.  We also have .bss.page_aligned, so use that.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86/traps: Put idt_table[] back into .bss

[Jan Beulich]

>>> On 09.03.18 at 16:03,  wrote:
> c/s d1d6fc97d "x86/xpti: really hide almost all of Xen image" accidentially
> moved idt_table[] from .bss to .data by virtue of using the page_aligned
> section.  We also have .bss.page_aligned, so use that.

Oops.

> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 2/2] x86: use invpcid to do global flushing

[Jan Beulich]

>>> On 05.03.18 at 10:50,  wrote:
> @@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va, unsigned 
> int flags)
>  else
>  {
>  u32 t = pre_flush();
> -unsigned long cr4 = read_cr4();
>  
> -write_cr4(cr4 & ~X86_CR4_PGE);
> -barrier();
> -write_cr4(cr4);
> +if ( !cpu_has_invpcid )
> +{
> +unsigned long cr4 = read_cr4();
> +
> +write_cr4(cr4 & ~X86_CR4_PGE);
> +barrier();
> +write_cr4(cr4);
> +}
> +else
> +{
> +/*
> + * Using invpcid to flush all mappings works
> + * regardless of whether PCID is enabled or not.
> + * It is faster than read-modify-write CR4.
> + */
> +invpcid_flush_all();
> +}

As just validly indicated by Jürgen, this is where my comment I
gave to one of his patches actually belongs: This is correct for
FLUSH_TLB_GLOBAL, but goes too far for FLUSH_TLB.

Jan

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

[Xen-devel] xen 4.10.0: stubdomain for HVM guest fails to start unless qdisk backend is used?

[Chris Brannon]

I recently made a build of xen 4.10.0 and installed it.
I have a pre-existing HVM guest that uses the following configuration:
1 hard drive using the phy disk backend.  The guest also uses a device
model stubdomain.  After upgrading, it refuses to start, due to a
stubdomain timeout:

Parsing config from somedomain
libxl: error: libxl_dm.c:2203:stubdom_xswait_cb: Domain 32:Stubdom 33 for 32 
startup: startup timed out
libxl: error: libxl_create.c:1538:domcreate_devmodel_started: Domain 32:device 
model did not start: -9
libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 32:Non-existant 
domain
libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 32:Unable to 
destroy guest
libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 32:Destruction of 
domain failed

There is nothing in the logs.

I noticed that a similar guest was booting with no issue.  The
difference was that the booting guest also had a CD-ROM attached.  That
CD-ROM used the qdisk backend, because it is backed by an ISO9660 image file.
I changed the disk parameter in the first non-booting guest so that it
used the qdisk backend rather than phy, and it booted with no trouble.

Has anyone else had an issue like this after upgrading to 4.10?  I did
some searching, and I didn't find anything.  I'm a bit surprised by
that.  Since this is so easy for me to reproduce, and no one else has
mentioned it, I wonder if my build could be subtly broken somehow.

-- Chris

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

Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC

[Wei Liu]

On Wed, Mar 07, 2018 at 03:44:22PM +, Lars Kurth wrote:
> 
> A2) Long-term, Larger series
> 
>  
> 
> Please call out any x86 related series, that need attention in the longer 
> term.
> Provide
> 
> * Title of series
> 
> * Link to series (e.g. on 
> https://lists.xenproject.org/archives/html/xen-devel,
> markmail, …)
> 
> * Describe any: Dependencies, Issues, etc. that are relevant
> 

I have one series that I haven't got an idea how to proceed:

[PATCH RFC 00/10] x86 passthrough code cleanup

https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01939.html

There isn't any dependency. I mostly want to know maintainers opinions
on what is required make passthrough code cleaner.

Wei.

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

[Xen-devel] [PATCH 12/17] ARM: VGIC: Introduce gic_get_nr_lrs()

[Andre Przywara]

So far the number of list registers (LRs) a GIC implements is only
needed in the hardware facing side of the VGIC code (gic-vgic.c).
The new VGIC will need this information in more and multiple places, so
export a function that returns the number.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/gic-vgic.c   | 10 +-
 xen/include/asm-arm/gic.h |  6 ++
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index f4c98bffd1..61f093db50 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 
-#define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs) - 
1))
+#define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_get_nr_lrs()) - 1))
 
 #undef GIC_DEBUG
 
@@ -110,7 +110,7 @@ static unsigned int gic_find_unused_lr(struct vcpu *v,
struct pending_irq *p,
unsigned int lr)
 {
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned int nr_lrs = gic_get_nr_lrs();
 unsigned long *lr_mask = (unsigned long *) _cpu(lr_mask);
 struct gic_lr lr_val;
 
@@ -137,7 +137,7 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int 
virtual_irq,
 unsigned int priority)
 {
 int i;
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned int nr_lrs = gic_get_nr_lrs();
 struct pending_irq *p = irq_to_pending(v, virtual_irq);
 
 ASSERT(spin_is_locked(>arch.vgic.lock));
@@ -251,7 +251,7 @@ void vgic_sync_from_lrs(struct vcpu *v)
 {
 int i = 0;
 unsigned long flags;
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned int nr_lrs = gic_get_nr_lrs();
 
 /* The idle domain has no LRs to be cleared. Since gic_restore_state
  * doesn't write any LR registers for the idle domain they could be
@@ -278,7 +278,7 @@ static void gic_restore_pending_irqs(struct vcpu *v)
 struct pending_irq *p, *t, *p_r;
 struct list_head *inflight_r;
 unsigned long flags;
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned int nr_lrs = gic_get_nr_lrs();
 int lrs = nr_lrs;
 
 spin_lock_irqsave(>arch.vgic.lock, flags);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index ff0b22451b..49cb94f792 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -374,6 +374,12 @@ struct gic_hw_operations {
 };
 
 extern const struct gic_hw_operations *gic_hw_ops;
+
+static inline unsigned int gic_get_nr_lrs(void)
+{
+return gic_hw_ops->info->nr_lrs;
+}
+
 void register_gic_ops(const struct gic_hw_operations *ops);
 int gic_make_hwdom_dt_node(const struct domain *d,
const struct dt_device_node *gic,
-- 
2.14.1


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

[Xen-devel] [PATCH 09/17] ARM: VGIC: change to level-IRQ compatible IRQ injection interface

[Andre Przywara]

At the moment vgic_vcpu_inject_irq() is the interface for Xen internal
code and virtual devices to inject IRQs into a guest. This interface has
two shortcomings:
1) It requires a VCPU pointer, which we may not know (and don't need!)
for shared interrupts. A second function (vgic_vcpu_inject_spi()), was
there to work around this issue.
2) This interface only really supports edge triggered IRQs, which is
what the Xen VGIC emulates only anyway. However this needs to and will
change, so we need to add the desired level (high or low) to the
interface.
This replaces the existing injection call (taking a VCPU and an IRQ
parameter) with a new one, taking domain, VCPU, IRQ and level parameters.
The VCPU can be NULL in case we don't know and don't care.
We change all call sites to use this new interface. This still doesn't
give us the missing level IRQ handling, but at least prepares the callers
to do the right thing later automatically.

Signed-off-by: Andre Przywara 
---
Changelog:
- keep function as returning void

 xen/arch/arm/domain.c  |  4 ++--
 xen/arch/arm/gic-v3-lpi.c  |  2 +-
 xen/arch/arm/irq.c |  2 +-
 xen/arch/arm/time.c|  2 +-
 xen/arch/arm/vgic.c| 39 +++
 xen/arch/arm/vpl011.c  |  2 +-
 xen/arch/arm/vtimer.c  |  4 ++--
 xen/include/asm-arm/vgic.h |  4 ++--
 8 files changed, 33 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 6b902fa30f..bc10f412ba 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -951,14 +951,14 @@ void vcpu_mark_events_pending(struct vcpu *v)
 if ( already_pending )
 return;
 
-vgic_vcpu_inject_irq(v, v->domain->arch.evtchn_irq);
+vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
 }
 
 /* The ARM spec declares that even if local irqs are masked in
  * the CPSR register, an irq should wake up a cpu from WFI anyway.
  * For this reason we need to check for irqs that need delivery,
  * ignoring the CPSR register, *after* calling SCHEDOP_block to
- * avoid races with vgic_vcpu_inject_irq.
+ * avoid races with vgic_inject_irq.
  */
 void vcpu_block_unless_event_pending(struct vcpu *v)
 {
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 84582157b8..efd5cd62fb 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -153,7 +153,7 @@ void vgic_vcpu_inject_lpi(struct domain *d, unsigned int 
virq)
 if ( vcpu_id >= d->max_vcpus )
   return;
 
-vgic_vcpu_inject_irq(d->vcpu[vcpu_id], virq);
+vgic_inject_irq(d, d->vcpu[vcpu_id], virq, true);
 }
 
 /*
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 29af10e82c..aa4e832cae 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -225,7 +225,7 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
  * The irq cannot be a PPI, we only support delivery of SPIs to
  * guests.
 */
-vgic_vcpu_inject_spi(info->d, info->virq);
+vgic_inject_irq(info->d, NULL, info->virq, true);
 goto out_no_end;
 }
 
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 36f640f0c1..c11fcfeadd 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -260,7 +260,7 @@ static void vtimer_interrupt(int irq, void *dev_id, struct 
cpu_user_regs *regs)
 
 current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
 WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, CNTV_CTL_EL0);
-vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
+vgic_inject_irq(current->domain, current, current->arch.virt_timer.irq, 
true);
 }
 
 /*
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index fa00c21a69..eb09d9ca54 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -291,7 +291,7 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, 
unsigned int irq)
 vgic_remove_irq_from_queues(old, p);
 irq_set_affinity(p->desc, cpumask_of(new->processor));
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
-vgic_vcpu_inject_irq(new, irq);
+vgic_inject_irq(new->domain, new, irq, true);
 return true;
 }
 /* if the IRQ is in a GICH_LR register, set GIC_IRQ_GUEST_MIGRATING
@@ -450,7 +450,7 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
gic_sgi_mode irqmode,
 sgir, target->list);
 continue;
 }
-vgic_vcpu_inject_irq(d->vcpu[vcpuid], virq);
+vgic_inject_irq(d, d->vcpu[vcpuid], virq, true);
 }
 break;
 case SGI_TARGET_OTHERS:
@@ -459,12 +459,12 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
gic_sgi_mode irqmode,
 {
 if ( i != current->vcpu_id && d->vcpu[i] != NULL &&
  is_vcpu_online(d->vcpu[i]) )
-vgic_vcpu_inject_irq(d->vcpu[i], virq);
+vgic_inject_irq(d, d->vcpu[i], virq, 

[Xen-devel] [PATCH 13/17] ARM: GICv3: rename HYP interface definitions to use ICH_ prefix

[Andre Przywara]

On a GICv3 in non-compat mode the hypervisor interface is always
accessed via system registers. Those register names have a "ICH_" prefix
in the manual, to differentiate them from the MMIO registers. Also those
registers are mostly 64-bit (compared to the 32-bit GICv2 registers) and
use different bit assignments.
To make this obvious and to avoid clashes with double definitions using
the same names for actually different bits, lets change all GICv3
hypervisor interface registers to use the "ICH_" prefix from the manual.
This renames the definitions in gic_v3_defs.h and their usage in gic-v3.c
and is needed to allow co-existence of the GICv2 and GICv3 definitions
in the same file.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/gic-v3.c | 48 +++---
 xen/include/asm-arm/gic_v3_defs.h | 49 +++
 2 files changed, 48 insertions(+), 49 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 4acdd0ad91..8b41704cf1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -828,14 +828,14 @@ static void gicv3_hyp_init(void)
 uint32_t vtr;
 
 vtr = READ_SYSREG32(ICH_VTR_EL2);
-gicv3_info.nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
-gicv3.nr_priorities = ((vtr >> GICH_VTR_PRIBITS_SHIFT) &
-  GICH_VTR_PRIBITS_MASK) + 1;
+gicv3_info.nr_lrs  = (vtr & ICH_VTR_NRLRGS) + 1;
+gicv3.nr_priorities = ((vtr >> ICH_VTR_PRIBITS_SHIFT) &
+  ICH_VTR_PRIBITS_MASK) + 1;
 
 if ( !((gicv3.nr_priorities > 4) && (gicv3.nr_priorities < 8)) )
 panic("GICv3: Invalid number of priority bits\n");
 
-WRITE_SYSREG32(GICH_VMCR_EOI | GICH_VMCR_VENG1, ICH_VMCR_EL2);
+WRITE_SYSREG32(ICH_VMCR_EOI | ICH_VMCR_VENG1, ICH_VMCR_EL2);
 WRITE_SYSREG32(GICH_HCR_EN, ICH_HCR_EL2);
 }
 
@@ -974,21 +974,21 @@ static void gicv3_update_lr(int lr, unsigned int virq, 
uint8_t priority,
 BUG_ON(lr >= gicv3_info.nr_lrs);
 BUG_ON(lr < 0);
 
-val =  (((uint64_t)state & 0x3) << GICH_LR_STATE_SHIFT);
+val =  (((uint64_t)state & 0x3) << ICH_LR_STATE_SHIFT);
 
 /*
  * When the guest is GICv3, all guest IRQs are Group 1, as Group0
  * would result in a FIQ in the guest, which it wouldn't expect
  */
 if ( current->domain->arch.vgic.version == GIC_V3 )
-val |= GICH_LR_GRP1;
+val |= ICH_LR_GRP1;
 
-val |= (uint64_t)priority << GICH_LR_PRIORITY_SHIFT;
-val |= ((uint64_t)virq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT;
+val |= (uint64_t)priority << ICH_LR_PRIORITY_SHIFT;
+val |= ((uint64_t)virq & ICH_LR_VIRTUAL_MASK) << ICH_LR_VIRTUAL_SHIFT;
 
if ( hw_irq != INVALID_IRQ )
-   val |= GICH_LR_HW | (((uint64_t)hw_irq & GICH_LR_PHYSICAL_MASK)
-   << GICH_LR_PHYSICAL_SHIFT);
+   val |= ICH_LR_HW | (((uint64_t)hw_irq & ICH_LR_PHYSICAL_MASK)
+   << ICH_LR_PHYSICAL_SHIFT);
 
 gicv3_ich_write_lr(lr, val);
 }
@@ -1004,25 +1004,25 @@ static void gicv3_read_lr(int lr, struct gic_lr *lr_reg)
 
 lrv = gicv3_ich_read_lr(lr);
 
-lr_reg->pirq = (lrv >> GICH_LR_PHYSICAL_SHIFT) & GICH_LR_PHYSICAL_MASK;
-lr_reg->virq = (lrv >> GICH_LR_VIRTUAL_SHIFT) & GICH_LR_VIRTUAL_MASK;
+lr_reg->pirq = (lrv >> ICH_LR_PHYSICAL_SHIFT) & ICH_LR_PHYSICAL_MASK;
+lr_reg->virq = (lrv >> ICH_LR_VIRTUAL_SHIFT) & ICH_LR_VIRTUAL_MASK;
 
-lr_reg->priority  = (lrv >> GICH_LR_PRIORITY_SHIFT) & 
GICH_LR_PRIORITY_MASK;
-lr_reg->state = (lrv >> GICH_LR_STATE_SHIFT) & GICH_LR_STATE_MASK;
-lr_reg->hw_status = (lrv >> GICH_LR_HW_SHIFT) & GICH_LR_HW_MASK;
-lr_reg->grp   = (lrv >> GICH_LR_GRP_SHIFT) & GICH_LR_GRP_MASK;
+lr_reg->priority  = (lrv >> ICH_LR_PRIORITY_SHIFT) & ICH_LR_PRIORITY_MASK;
+lr_reg->state = (lrv >> ICH_LR_STATE_SHIFT) & ICH_LR_STATE_MASK;
+lr_reg->hw_status = (lrv >> ICH_LR_HW_SHIFT) & ICH_LR_HW_MASK;
+lr_reg->grp   = (lrv >> ICH_LR_GRP_SHIFT) & ICH_LR_GRP_MASK;
 }
 
 static void gicv3_write_lr(int lr_reg, const struct gic_lr *lr)
 {
 uint64_t lrv = 0;
 
-lrv = ( ((u64)(lr->pirq & GICH_LR_PHYSICAL_MASK) << 
GICH_LR_PHYSICAL_SHIFT)|
-((u64)(lr->virq & GICH_LR_VIRTUAL_MASK)  << GICH_LR_VIRTUAL_SHIFT) |
-((u64)(lr->priority & GICH_LR_PRIORITY_MASK) << 
GICH_LR_PRIORITY_SHIFT)|
-((u64)(lr->state & GICH_LR_STATE_MASK) << GICH_LR_STATE_SHIFT) |
-((u64)(lr->hw_status & GICH_LR_HW_MASK) << GICH_LR_HW_SHIFT)  |
-((u64)(lr->grp & GICH_LR_GRP_MASK) << GICH_LR_GRP_SHIFT) );
+lrv = ( ((u64)(lr->pirq & ICH_LR_PHYSICAL_MASK) << ICH_LR_PHYSICAL_SHIFT)|
+((u64)(lr->virq & ICH_LR_VIRTUAL_MASK)  << ICH_LR_VIRTUAL_SHIFT) |
+((u64)(lr->priority & ICH_LR_PRIORITY_MASK) << ICH_LR_PRIORITY_SHIFT)|
+((u64)(lr->state & ICH_LR_STATE_MASK) << ICH_LR_STATE_SHIFT) |
+

[Xen-devel] [PATCH 16/17] ARM: GICv3: poke_irq: make RWP optional

[Andre Przywara]

A GICv3 hardware implementation can be implemented in several parts that
communicate with each other (think multi-socket systems).
To make sure that critical settings have arrived at all endpoints, some
bits are tracked using the RWP bit in the GICD_CTLR register, which
signals whether a register write is still in progress.
However this only applies to *some* registers, namely the bits in the
GICD_ICENABLER (disabling interrupts) and some bits in the GICD_CTLR
register (cf. Arm IHI 0069D, 8.9.4: RWP, bit[31]).
But our gicv3_poke_irq() was always polling this bit before returning,
resulting in pointless MMIO reads for many registers.
Add an option to gicv3_poke_irq() to state whether we want to wait for
this bit and use it accordingly to match the spec.
Replace a "1 << " with a "1U << " on the way to fix a potentially
undefined behaviour when the argument evaluates to 31.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/gic-v3.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 8b41704cf1..09b49a07d5 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -428,9 +428,9 @@ static void gicv3_dump_state(const struct vcpu *v)
 }
 }
 
-static void gicv3_poke_irq(struct irq_desc *irqd, u32 offset)
+static void gicv3_poke_irq(struct irq_desc *irqd, u32 offset, bool 
wait_for_rwp)
 {
-u32 mask = 1 << (irqd->irq % 32);
+u32 mask = 1U << (irqd->irq % 32);
 void __iomem *base;
 
 if ( irqd->irq < NR_GIC_LOCAL_IRQS )
@@ -439,17 +439,19 @@ static void gicv3_poke_irq(struct irq_desc *irqd, u32 
offset)
 base = GICD;
 
 writel_relaxed(mask, base + offset + (irqd->irq / 32) * 4);
-gicv3_wait_for_rwp(irqd->irq);
+
+if ( wait_for_rwp )
+gicv3_wait_for_rwp(irqd->irq);
 }
 
 static void gicv3_unmask_irq(struct irq_desc *irqd)
 {
-gicv3_poke_irq(irqd, GICD_ISENABLER);
+gicv3_poke_irq(irqd, GICD_ISENABLER, false);
 }
 
 static void gicv3_mask_irq(struct irq_desc *irqd)
 {
-gicv3_poke_irq(irqd, GICD_ICENABLER);
+gicv3_poke_irq(irqd, GICD_ICENABLER, true);
 }
 
 static void gicv3_eoi_irq(struct irq_desc *irqd)
-- 
2.14.1


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

[Xen-devel] [PATCH 15/17] ARM: GICv2: introduce gicv2_poke_irq()

[Andre Przywara]

The GICv2 uses bitmaps spanning several MMIO registers for holding some
interrupt state. Similar to GICv3, add a poke helper functions to set a bit
for a given irq_desc in one of those bitmaps.
At the moment there is only one use in gic-v2.c, but there will be more
coming soon.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2b271ba322..fa9afc2be8 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -235,6 +235,11 @@ static unsigned int gicv2_read_irq(void)
 return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
 }
 
+static void gicv2_poke_irq(struct irq_desc *irqd, uint32_t offset)
+{
+writel_gicd(1U << (irqd->irq % 32), offset + (irqd->irq / 32) * 4);
+}
+
 static void gicv2_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
 uint32_t cfg, actual, edgebit;
@@ -509,7 +514,6 @@ static unsigned int gicv2_read_apr(int apr_reg)
 static void gicv2_irq_enable(struct irq_desc *desc)
 {
 unsigned long flags;
-int irq = desc->irq;
 
 ASSERT(spin_is_locked(>lock));
 
@@ -517,20 +521,19 @@ static void gicv2_irq_enable(struct irq_desc *desc)
 clear_bit(_IRQ_DISABLED, >status);
 dsb(sy);
 /* Enable routing */
-writel_gicd((1u << (irq % 32)), GICD_ISENABLER + (irq / 32) * 4);
+gicv2_poke_irq(desc, GICD_ISENABLER);
 spin_unlock_irqrestore(, flags);
 }
 
 static void gicv2_irq_disable(struct irq_desc *desc)
 {
 unsigned long flags;
-int irq = desc->irq;
 
 ASSERT(spin_is_locked(>lock));
 
 spin_lock_irqsave(, flags);
 /* Disable routing */
-writel_gicd(1u << (irq % 32), GICD_ICENABLER + (irq / 32) * 4);
+gicv2_poke_irq(desc, GICD_ICENABLER);
 set_bit(_IRQ_DISABLED, >status);
 spin_unlock_irqrestore(, flags);
 }
-- 
2.14.1


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

[Xen-devel] [PATCH 11/17] ARM: VGIC: reorder prototypes in vgic.h

[Andre Przywara]

Currently vgic.h both contains prototypes used by Xen arch code outside
of the actual VGIC (for instance vgic_vcpu_inject_irq()), and prototypes
for functions used by the VGIC internally.
Group them to later allow an easy split with one #ifdef.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/include/asm-arm/vgic.h | 54 +-
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index d6f550ff44..0787ba9549 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -279,49 +279,34 @@ enum gic_sgi_mode;
  */
 #define REG_RANK_INDEX(b, n, s) n) >> s) & ((b)-1)) % 32)
 
-/*
- * In the moment vgic_num_irqs() just covers SPIs and the private IRQs,
- * as it's mostly used for allocating the pending_irq and irq_desc array,
- * in which LPIs don't participate.
- */
-#define vgic_num_irqs(d)((d)->arch.vgic.nr_spis + 32)
 
-extern int domain_vgic_init(struct domain *d, unsigned int nr_spis);
-extern void domain_vgic_free(struct domain *d);
-extern int vcpu_vgic_init(struct vcpu *v);
 extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int virq);
-extern void vgic_inject_irq(struct domain *d, struct vcpu *v, unsigned int 
virq,
-bool level);
 extern void vgic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p);
 extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
-extern void vgic_clear_pending_irqs(struct vcpu *v);
 extern void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq);
 extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v, int b, int n, 
int s);
 extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq);
-extern bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr);
 extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n);
 extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n);
 extern void register_vgic_ops(struct domain *d, const struct vgic_ops *ops);
 int vgic_v2_init(struct domain *d, int *mmio_count);
 int vgic_v3_init(struct domain *d, int *mmio_count);
 
-bool vgic_evtchn_irq_pending(struct vcpu *v);
-struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
-  unsigned int virq);
-int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
-struct irq_desc *desc, bool connect);
-
-extern int domain_vgic_register(struct domain *d, int *mmio_count);
-extern int vcpu_vgic_free(struct vcpu *v);
 extern bool vgic_to_sgi(struct vcpu *v, register_t sgir,
 enum gic_sgi_mode irqmode, int virq,
 const struct sgi_target *target);
 extern bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned int 
irq);
 
-/* Reserve a specific guest vIRQ */
-extern bool vgic_reserve_virq(struct domain *d, unsigned int virq);
+/*** Common VGIC functions used by Xen arch code /
+
+/*
+ * In the moment vgic_num_irqs() just covers SPIs and the private IRQs,
+ * as it's mostly used for allocating the pending_irq and irq_desc array,
+ * in which LPIs don't participate.
+ */
+#define vgic_num_irqs(d)((d)->arch.vgic.nr_spis + 32)
 
 /*
  * Allocate a guest VIRQ
@@ -329,6 +314,9 @@ extern bool vgic_reserve_virq(struct domain *d, unsigned 
int virq);
  *  - spi == 1 => allocate an SPI
  */
 extern int vgic_allocate_virq(struct domain *d, bool spi);
+/* Reserve a specific guest vIRQ */
+extern bool vgic_reserve_virq(struct domain *d, unsigned int virq);
+extern void vgic_free_virq(struct domain *d, unsigned int virq);
 
 static inline int vgic_allocate_ppi(struct domain *d)
 {
@@ -340,7 +328,25 @@ static inline int vgic_allocate_spi(struct domain *d)
 return vgic_allocate_virq(d, true /* spi */);
 }
 
-extern void vgic_free_virq(struct domain *d, unsigned int virq);
+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
+  unsigned int virq);
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
+struct irq_desc *desc, bool connect);
+
+bool vgic_evtchn_irq_pending(struct vcpu *v);
+
+int domain_vgic_register(struct domain *d, int *mmio_count);
+int domain_vgic_init(struct domain *d, unsigned int nr_spis);
+void domain_vgic_free(struct domain *d);
+int vcpu_vgic_init(struct vcpu *vcpu);
+int vcpu_vgic_free(struct vcpu *vcpu);
+
+void vgic_inject_irq(struct domain *d, struct vcpu *v, unsigned int virq,
+ bool level);
+
+extern void vgic_clear_pending_irqs(struct vcpu *v);
+
+extern bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr);
 
 unsigned 

[Xen-devel] [PATCH 03/17] ARM: vGICv3: always use architected redist stride

[Andre Przywara]

The redistributor-stride property in a GICv3 DT node is only there to
cover broken platforms where this value deviates from the architected one.
Since we emulate the GICv3 distributor even for Dom0, we don't need to
copy the broken behaviour. All the special handling for Dom0s using
GICv3 is just for using the hardware's memory map, which is unaffected
by the redistributor stride - it can never be smaller than the
architected two pages.
Remove the redistributor-stride property from Dom0's DT node and also
remove the code that tried to reuse the hardware value for Dom0's GICv3
emulation.

Signed-off-by: Andre Przywara 
---
Changelog:
- merge in GICV3_GICR_SIZE definition

 xen/arch/arm/gic-v3.c |  4 
 xen/arch/arm/vgic-v3.c| 14 ++
 xen/include/asm-arm/gic_v3_defs.h |  5 +
 3 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b1f8a86409..047af691b1 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1162,10 +1162,6 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 if ( res )
 return res;
 
-res = fdt_property_cell(fdt, "redistributor-stride", gicv3.rdist_stride);
-if ( res )
-return res;
-
 res = fdt_property_cell(fdt, "#redistributor-regions", gicv3.rdist_count);
 if ( res )
 return res;
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d5b34a7d0f..56cc38ffcc 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1024,10 +1024,9 @@ static struct vcpu *get_vcpu_from_rdist(struct domain *d,
 paddr_t gpa, uint32_t *offset)
 {
 struct vcpu *v;
-uint32_t stride = d->arch.vgic.rdist_stride;
 unsigned int vcpu_id;
 
-vcpu_id = region->first_cpu + ((gpa - region->base) / stride);
+vcpu_id = region->first_cpu + ((gpa - region->base) / GICV3_GICR_SIZE);
 if ( unlikely(vcpu_id >= d->max_vcpus) )
 return NULL;
 
@@ -1586,7 +1585,6 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
 
 /* Convenient alias */
 struct domain *d = v->domain;
-uint32_t rdist_stride = d->arch.vgic.rdist_stride;
 
 /*
  * Find the region where the re-distributor lives. For this purpose,
@@ -1602,11 +1600,11 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
 
 /* Get the base address of the redistributor */
 rdist_base = region->base;
-rdist_base += (v->vcpu_id - region->first_cpu) * rdist_stride;
+rdist_base += (v->vcpu_id - region->first_cpu) * GICV3_GICR_SIZE;
 
 /* Check if a valid region was found for the re-distributor */
 if ( (rdist_base < region->base) ||
- ((rdist_base + rdist_stride) > (region->base + region->size)) )
+ ((rdist_base + GICV3_GICR_SIZE) > (region->base + region->size)) )
 {
 dprintk(XENLOG_ERR,
 "d%u: Unable to find a re-distributor for VCPU %u\n",
@@ -1622,7 +1620,7 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
  * VGIC_V3_RDIST_LAST flags.
  * Note that we are assuming max_vcpus will never change.
  */
-last_cpu = (region->size / rdist_stride) + region->first_cpu - 1;
+last_cpu = (region->size / GICV3_GICR_SIZE) + region->first_cpu - 1;
 
 if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
 v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;
@@ -1693,7 +1691,7 @@ static int vgic_v3_domain_init(struct domain *d)
 /* Set the first CPU handled by this region */
 d->arch.vgic.rdist_regions[i].first_cpu = first_cpu;
 
-first_cpu += size / d->arch.vgic.rdist_stride;
+first_cpu += size / GICV3_GICR_SIZE;
 }
 
 d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
@@ -1708,7 +1706,7 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
 
 /* The first redistributor should contain enough space for all CPUs */
-BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < 
MAX_VIRT_CPUS);
+BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GICV3_GICR_SIZE) < 
MAX_VIRT_CPUS);
 d->arch.vgic.rdist_regions[0].base = GUEST_GICV3_GICR0_BASE;
 d->arch.vgic.rdist_regions[0].size = GUEST_GICV3_GICR0_SIZE;
 d->arch.vgic.rdist_regions[0].first_cpu = 0;
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 65c9dc47cf..bb34d17eca 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -18,6 +18,8 @@
 #ifndef __ASM_ARM_GIC_V3_DEFS_H__
 #define __ASM_ARM_GIC_V3_DEFS_H__
 
+#include 
+
 /*
  * Additional registers defined in GIC v3.
  * Common GICD registers are defined in gic.h
@@ -68,6 +70,9 @@
 #define GICV3_GICD_IIDR_VAL  0x34c
 #define GICV3_GICR_IIDR_VAL  GICV3_GICD_IIDR_VAL
 
+/* Two pages for the RD_base and SGI_base register frame. */
+#define GICV3_GICR_SIZE  (2 * SZ_64K)
+
 #define 

[Xen-devel] [PATCH 14/17] ARM: Implement vcpu_kick()

[Andre Przywara]

If we change something in a vCPU that affects its runnability or
otherwise needs the vCPU's attention, we might need to tell the scheduler
about it.
We are using this in one place (vIRQ injection) at the moment, but will
need this at more places soon.
So let's factor out this functionality, using the already existing
vcpu_kick() prototype (used in x86 only so far), to make this available
to the rest of the Xen code.

Signed-off-by: Andre Przywara 
---
- Rename to vcpu_kick(), to blend in with existing (x86) prototype

 xen/arch/arm/domain.c | 12 
 xen/arch/arm/vgic.c   | 11 +++
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index bc10f412ba..650712e0f2 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -967,6 +967,18 @@ void vcpu_block_unless_event_pending(struct vcpu *v)
 vcpu_unblock(current);
 }
 
+void vcpu_kick(struct vcpu *vcpu)
+{
+bool running = vcpu->is_running;
+
+vcpu_unblock(vcpu);
+if ( running && vcpu != current )
+{
+perfc_incr(vgic_cross_cpu_intr_inject);
+smp_send_event_check_mask(cpumask_of(vcpu->processor));
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index eb09d9ca54..3fafdd0b66 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -530,7 +531,6 @@ void vgic_inject_irq(struct domain *d, struct vcpu *v, 
unsigned int virq,
 uint8_t priority;
 struct pending_irq *iter, *n;
 unsigned long flags;
-bool running;
 
 /*
  * For edge triggered interrupts we always ignore a "falling edge".
@@ -590,14 +590,9 @@ void vgic_inject_irq(struct domain *d, struct vcpu *v, 
unsigned int virq,
 list_add_tail(>inflight, >arch.vgic.inflight_irqs);
 out:
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
 /* we have a new higher priority irq, inject it into the guest */
-running = v->is_running;
-vcpu_unblock(v);
-if ( running && v != current )
-{
-perfc_incr(vgic_cross_cpu_intr_inject);
-smp_send_event_check_mask(cpumask_of(v->processor));
-}
+vcpu_kick(v);
 
 return;
 }
-- 
2.14.1


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

[Xen-devel] [PATCH 05/17] ARM: VGIC: rename gic_inject() and gic_clear_lrs()

[Andre Przywara]

The two central functions to synchronise our emulated VGIC state with
the GIC hardware (the LRs, really), are named somewhat confusingly.
Rename them from gic_inject() to vgic_sync_to_lrs() and from
gic_clear_lrs() to vgic_sync_from_lrs(), to make the code more readable.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/gic-vgic.c   | 4 ++--
 xen/arch/arm/traps.c  | 4 ++--
 xen/include/asm-arm/gic.h | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index d273863556..c0fe38fd37 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -247,7 +247,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 }
 }
 
-void gic_clear_lrs(struct vcpu *v)
+void vgic_sync_from_lrs(struct vcpu *v)
 {
 int i = 0;
 unsigned long flags;
@@ -377,7 +377,7 @@ out:
 return rc;
 }
 
-void gic_inject(void)
+void vgic_sync_to_lrs(void)
 {
 ASSERT(!local_irq_is_enabled());
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1cba7e584d..7411bff7a7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,7 +2024,7 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
 if ( current->arch.hcr_el2 & HCR_VA )
 current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
 
-gic_clear_lrs(current);
+vgic_sync_from_lrs(current);
 }
 }
 
@@ -2234,7 +2234,7 @@ void leave_hypervisor_tail(void)
 {
 local_irq_disable();
 if (!softirq_pending(smp_processor_id())) {
-gic_inject();
+vgic_sync_to_lrs();
 
 /*
  * If the SErrors handle option is "DIVERSE", we have to prevent
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 497f195bc1..e2ae4254ed 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -237,7 +237,7 @@ extern int gic_route_irq_to_guest(struct domain *, unsigned 
int virq,
 int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
   struct irq_desc *desc);
 
-extern void gic_inject(void);
+extern void vgic_sync_to_lrs(void);
 extern void gic_clear_pending_irqs(struct vcpu *v);
 extern int gic_events_need_delivery(void);
 
@@ -295,7 +295,7 @@ extern unsigned int gic_number_lines(void);
 /* IRQ translation function for the device tree */
 int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
   unsigned int *out_hwirq, unsigned int *out_type);
-void gic_clear_lrs(struct vcpu *v);
+void vgic_sync_from_lrs(struct vcpu *v);
 
 struct gic_info {
 /* GIC version */
-- 
2.14.1


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

[Xen-devel] [PATCH 17/17] ARM: GICv2: fix GICH_V2_LR definitions

[Andre Przywara]

The bit definition for the CPUID mask in the GICv2 LR register was
wrong, fortunately the current implementation does not use that bit.
Fix it up (it's starting at bit 10, not bit 9) and clean up some
nearby definitions on the way.
This will be used by the new VGIC shortly.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index fa9afc2be8..f16e17c1a3 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -57,10 +57,11 @@
 #define GICH_V2_LR_HW_MASK 0x1
 #define GICH_V2_LR_GRP_SHIFT   30
 #define GICH_V2_LR_GRP_MASK0x1
-#define GICH_V2_LR_MAINTENANCE_IRQ (1<<19)
-#define GICH_V2_LR_GRP1(1<<30)
-#define GICH_V2_LR_HW  (1<<31)
-#define GICH_V2_LR_CPUID_SHIFT 9
+#define GICH_V2_LR_MAINTENANCE_IRQ (1U << 19)
+#define GICH_V2_LR_GRP1(1U << 30)
+#define GICH_V2_LR_HW  (1U << GICH_V2_LR_HW_SHIFT)
+#define GICH_V2_LR_CPUID_SHIFT 10
+#define GICH_V2_LR_CPUID_MASK  0x7
 #define GICH_V2_VTR_NRLRGS 0x3f
 
 #define GICH_V2_VMCR_PRIORITY_MASK   0x1f
-- 
2.14.1


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

[Xen-devel] [PATCH 02/17] ARM: GICv3: use hardware GICv3 redistributor values for Dom0

[Andre Przywara]

The code to generate the DT node or MADT table for Dom0 reaches into the
domain's vGIC structure to learn the number of redistributor regions and
their base addresses.
Since those values are copied from the hardware, we can as well use
those hardware values directly when setting up the hardware domain.

This avoids the hardware GIC code to reference vGIC data structures.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/gic-v3.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 25c30bb9ea..b1f8a86409 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1162,13 +1162,11 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 if ( res )
 return res;
 
-res = fdt_property_cell(fdt, "redistributor-stride",
-d->arch.vgic.rdist_stride);
+res = fdt_property_cell(fdt, "redistributor-stride", gicv3.rdist_stride);
 if ( res )
 return res;
 
-res = fdt_property_cell(fdt, "#redistributor-regions",
-d->arch.vgic.nr_regions);
+res = fdt_property_cell(fdt, "#redistributor-regions", gicv3.rdist_count);
 if ( res )
 return res;
 
@@ -1178,7 +1176,7 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
  * CPU interface and virtual cpu interfaces accessesed as System registers
  * So cells are created only for Distributor and rdist regions
  */
-new_len = new_len * (d->arch.vgic.nr_regions + 1);
+new_len = new_len * (gicv3.rdist_count + 1);
 
 hw_reg = dt_get_property(gic, "reg", );
 if ( !hw_reg )
@@ -1406,13 +1404,13 @@ static int gicv3_make_hwdom_madt(const struct domain 
*d, u32 offset)
 
 /* Add Generic Redistributor */
 size = sizeof(struct acpi_madt_generic_redistributor);
-for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
+for ( i = 0; i < gicv3.rdist_count; i++ )
 {
 gicr = (struct acpi_madt_generic_redistributor *)(base_ptr + 
table_len);
 gicr->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
 gicr->header.length = size;
-gicr->base_address = d->arch.vgic.rdist_regions[i].base;
-gicr->length = d->arch.vgic.rdist_regions[i].size;
+gicr->base_address = gicv3.rdist_regions[i].base;
+gicr->length = gicv3.rdist_regions[i].size;
 table_len += size;
 }
 
@@ -1425,8 +1423,7 @@ static unsigned long 
gicv3_get_hwdom_extra_madt_size(const struct domain *d)
 {
 unsigned long size;
 
-size = sizeof(struct acpi_madt_generic_redistributor)
-   * d->arch.vgic.nr_regions;
+size = sizeof(struct acpi_madt_generic_redistributor) * gicv3.rdist_count;
 
 size += sizeof(struct acpi_madt_generic_translator)
 * vgic_v3_its_count(d);
-- 
2.14.1


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

[Xen-devel] [PATCH 08/17] ARM: VGIC: rename gic_event_needs_delivery()

[Andre Przywara]

gic_event_needs_delivery() is not named very intuitively, especially
the gic_ prefix is somewhat misleading.
Rename it to vgic_pending_irq(), which makes it clear that this relates
to the virtual GIC and is about interrupts.

Signed-off-by: Andre Przywara 
---
Changelog:
- Add vcpu parameter
- Rename to vgic_vcpu_pending_irq()

 xen/arch/arm/gic-vgic.c | 16 ++--
 xen/include/asm-arm/event.h |  2 +-
 xen/include/asm-arm/gic.h   |  2 +-
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index c0fe38fd37..f4c98bffd1 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -339,9 +339,18 @@ void gic_clear_pending_irqs(struct vcpu *v)
 gic_remove_from_lr_pending(v, p);
 }
 
-int gic_events_need_delivery(void)
+/**
+ * vgic_vcpu_pending_irq() - determine if interrupts need to be injected
+ * @vcpu: The vCPU on which to check for interrupts.
+ *
+ * Checks whether there is an interrupt on the given VCPU which needs
+ * handling in the guest. This requires at least one IRQ to be pending
+ * and enabled.
+ *
+ * Returns: 1 if the guest should run to handle interrupts, 0 otherwise.
+ */
+int vgic_vcpu_pending_irq(struct vcpu *v)
 {
-struct vcpu *v = current;
 struct pending_irq *p;
 unsigned long flags;
 const unsigned long apr = gic_hw_ops->read_apr(0);
@@ -349,6 +358,9 @@ int gic_events_need_delivery(void)
 int active_priority;
 int rc = 0;
 
+/* We rely on reading the VMCR, which is only accessible locally. */
+ASSERT(v == current);
+
 mask_priority = gic_hw_ops->read_vmcr_priority();
 active_priority = find_next_bit(, 32, 0);
 
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index e8c2a6cb44..c7a415ef57 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -24,7 +24,7 @@ static inline int local_events_need_delivery_nomask(void)
  * interrupts disabled so this shouldn't be a problem in the general
  * case.
  */
-if ( gic_events_need_delivery() )
+if ( vgic_vcpu_pending_irq(current) )
 return 1;
 
 if ( !vcpu_info(current, evtchn_upcall_pending) )
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 3b2d0217a6..ff0b22451b 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -238,7 +238,7 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned 
int virq,
 
 extern void vgic_sync_to_lrs(void);
 extern void gic_clear_pending_irqs(struct vcpu *v);
-extern int gic_events_need_delivery(void);
+extern int vgic_vcpu_pending_irq(struct vcpu *v);
 
 extern void init_maintenance_interrupt(void);
 extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
-- 
2.14.1


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

[Xen-devel] [PATCH 04/17] ARM: vGICv3: remove rdist_stride from VGIC structure

[Andre Przywara]

The last patch removed the usage of the hardware's redistributor-stride
value from our (Dom0) GICv3 emulation. This means we no longer need to
store this value in the VGIC data structure.
Remove that variable and every code snippet that handled that, instead
simply always use the architected value.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/gic-v3.c |  3 +--
 xen/arch/arm/vgic-v3.c| 14 --
 xen/include/asm-arm/domain.h  |  1 -
 xen/include/asm-arm/vgic.h|  1 -
 xen/include/public/arch-arm.h |  1 -
 5 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 047af691b1..4acdd0ad91 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1680,8 +1680,7 @@ static int __init gicv3_init(void)
 reg = readl_relaxed(GICD + GICD_TYPER);
 intid_bits = GICD_TYPE_ID_BITS(reg);
 
-vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
- gicv3.rdist_stride, intid_bits);
+vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions, 
intid_bits);
 gicv3_init_v2();
 
 spin_lock_init();
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 56cc38ffcc..4b42739a52 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -58,21 +58,18 @@ static struct {
 /* Re-distributor regions */
 unsigned int nr_rdist_regions;
 const struct rdist_region *regions;
-uint32_t rdist_stride; /* Re-distributor stride */
 unsigned int intid_bits;  /* Number of interrupt ID bits */
 } vgic_v3_hw;
 
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
   const struct rdist_region *regions,
-  uint32_t rdist_stride,
   unsigned int intid_bits)
 {
 vgic_v3_hw.enabled = true;
 vgic_v3_hw.dbase = dbase;
 vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
 vgic_v3_hw.regions = regions;
-vgic_v3_hw.rdist_stride = rdist_stride;
 vgic_v3_hw.intid_bits = intid_bits;
 }
 
@@ -1672,15 +1669,6 @@ static int vgic_v3_domain_init(struct domain *d)
 
 d->arch.vgic.dbase = vgic_v3_hw.dbase;
 
-d->arch.vgic.rdist_stride = vgic_v3_hw.rdist_stride;
-/*
- * If the stride is not set, the default stride for GICv3 is 2 * 64K:
- * - first 64k page for Control and Physical LPIs
- * - second 64k page for Control and Generation of SGIs
- */
-if ( !d->arch.vgic.rdist_stride )
-d->arch.vgic.rdist_stride = 2 * SZ_64K;
-
 for ( i = 0; i < vgic_v3_hw.nr_rdist_regions; i++ )
 {
 paddr_t size = vgic_v3_hw.regions[i].size;
@@ -1703,8 +1691,6 @@ static int vgic_v3_domain_init(struct domain *d)
 /* A single Re-distributor region is mapped for the guest. */
 BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
 
-d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
-
 /* The first redistributor should contain enough space for all CPUs */
 BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GICV3_GICR_SIZE) < 
MAX_VIRT_CPUS);
 d->arch.vgic.rdist_regions[0].base = GUEST_GICV3_GICR0_BASE;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 0dd8c954e2..aee247a037 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -105,7 +105,6 @@ struct arch_domain
 unsigned int first_cpu; /* First CPU handled */
 } *rdist_regions;
 int nr_regions; /* Number of rdist regions */
-uint32_t rdist_stride;  /* Re-Distributor stride */
 unsigned long int nr_lpis;
 uint64_t rdist_propbase;
 struct rb_root its_devices; /* Devices mapped to an ITS */
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 6ea9f140a7..d61b54867b 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -261,7 +261,6 @@ struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
   const struct rdist_region *regions,
-  uint32_t rdist_stride,
   unsigned int intid_bits);
 #endif
 
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 05fd11ca38..eb424e8286 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -401,7 +401,6 @@ typedef uint64_t xen_callback_t;
 #define GUEST_GICV3_GICD_BASE  xen_mk_ullong(0x03001000)
 #define GUEST_GICV3_GICD_SIZE  xen_mk_ullong(0x0001)
 
-#define GUEST_GICV3_RDIST_STRIDE   xen_mk_ullong(0x0002)
 #define GUEST_GICV3_RDIST_REGIONS  1
 
 #define GUEST_GICV3_GICR0_BASE xen_mk_ullong(0x0302) /* vCPU0..127 */
-- 
2.14.1


___
Xen-devel mailing list

[Xen-devel] [PATCH 06/17] ARM: VGIC: Move gic_remove_from_lr_pending() prototype

[Andre Przywara]

The prototype for gic_remove_from_lr_pending() is the last function in
gic.h which references a VGIC data structure.
Move it over to vgic.h, so that we can remove the inclusion of vgic.h
from gic.h. We add it to asm/domain.h instead, where it is actually
needed.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/include/asm-arm/domain.h | 1 +
 xen/include/asm-arm/gic.h| 2 --
 xen/include/asm-arm/vgic.h   | 1 +
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index aee247a037..c6aa5cf389 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index e2ae4254ed..3b2d0217a6 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,7 +156,6 @@
 #ifndef __ASSEMBLY__
 #include 
 #include 
-#include 
 
 #define DT_COMPAT_GIC_CORTEX_A15 "arm,cortex-a15-gic"
 
@@ -245,7 +244,6 @@ extern void init_maintenance_interrupt(void);
 extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
 unsigned int priority);
 extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
-extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
 
 /* Accept an interrupt from the GIC and dispatch its handler */
 extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index d61b54867b..d03298e12c 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -205,6 +205,7 @@ extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, 
unsigned int virq);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq);
 extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
 extern void vgic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p);
+extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
 extern void vgic_clear_pending_irqs(struct vcpu *v);
 extern void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
-- 
2.14.1


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

[Xen-devel] [PATCH] x86/traps: Put idt_table[] back into .bss

[Andrew Cooper]

c/s d1d6fc97d "x86/xpti: really hide almost all of Xen image" accidentially
moved idt_table[] from .bss to .data by virtue of using the page_aligned
section.  We also have .bss.page_aligned, so use that.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 xen/arch/x86/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 19bc174..016af12 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -102,7 +102,7 @@ DEFINE_PER_CPU_READ_MOSTLY(struct desc_struct *, gdt_table);
 DEFINE_PER_CPU_READ_MOSTLY(struct desc_struct *, compat_gdt_table);
 
 /* Master table, used by CPU0. */
-idt_entry_t __section(".data.page_aligned") __aligned(PAGE_SIZE)
+idt_entry_t __section(".bss.page_aligned") __aligned(PAGE_SIZE)
 idt_table[IDT_ENTRIES];
 
 /* Pointer to the IDT of every CPU. */
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 7/7] xen/mm: Clean up share_xen_page_with_guest() API

[Wei Liu]

On Fri, Mar 09, 2018 at 01:18:42PM +, Andrew Cooper wrote:
> The share_xen_page_with_guest() functions are used by common code, and are
> implemented the same by each arch.  Move the declarations into the common mm.h
> rather than duplicating them in each arch/mm.h
> 
> Turn an int readonly into a boolean enum, to retain ro/rw context at the
> callsites, but use shorter labels which avoids a large number of split lines.
> 
> Implement share_xen_page_with_privileged_guests() as a static inline wrapper
> around share_xen_page_with_guest() to avoid having a call into a separate
> translation unit whose only purpose is to shuffle function arguments.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 6/7] xen/domain: Pass the full domctl_createdomain struct to create_domain()

[Wei Liu]

On Fri, Mar 09, 2018 at 01:18:41PM +, Andrew Cooper wrote:
> In future patches, the structure will be extended with further information,
> and this is far cleaner than adding extra parameters.
> 
> One minor tweak is that the setting of guest_type needs to be deferred until
> config is known-good to dereference, but this doesn't result in any changed
> behaviour as system domains never used to pass XEN_DOMCTL_CDF_hvm_guest.
> 
> Also for completeness, move the setting of d->handle into the tail of
> domain_create() where it more logically should live.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 5/7] x86/domain: Optimise the order of actions in arch_domain_create()

[Wei Liu]

On Fri, Mar 09, 2018 at 01:18:40PM +, Andrew Cooper wrote:
> The only relevent initialisation for the idle domain is the context switch and
> poisoned pointers.  Collect these bits together early in the function and exit
> when complete (although as a consequence, the e820 and vtsc lock
> initialisation are moved forwards).  This allows us to remove subsequent
> is_idle_domain() checks and unindent most of the logic.
> 
> Furthermore, we no longer call these functions for the idle domain:
>  * mapcache_domain_init() and tsc_set_info() were previously guarded against
>the idle domain, and have had their guards turned into ASSERT()s.
>  * pit_init() is implicitly guarded by has_vpit().
>  * psr_domain_init() no longer allocates a socket array.
> 
> Finally, two changes are introduced for the benefit of the following patch:
>  * For PV hardware domains, or XEN_X86_EMU_PIT into emflags rather than into
>config->emulation_flags, to facilitating config becoming const.
>  * References to domcr_flags are moved until after the idle early exist, to
>facilitiate them being unavailable for system domains.
> 
> No practical change in behaviour.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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