Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

2017-01-26 Thread Jan Beulich 
>>> On 26.01.17 at 19:39,  wrote:
> Does the below answer your question?

I think that's fine, once added to the actual patch description.

Jan

> On 01/05/2017 08:07 PM, Oleksandr Andrushchenko wrote:
>> On 01/05/2017 06:12 PM, Jan Beulich wrote:
>> On 05.01.17 at 17:03,  wrote:
 On 01/05/2017 05:45 PM, Jan Beulich wrote:
 On 22.12.16 at 09:12,  wrote:
> Other than that the primary thing I'm missing (as I think I've
> mentioned elsewhere already) is a rationale of why this new
> protocol is needed (and the existing xenfb one can't be extended).
 "This protocol aims to provide a unified protocol which fits more

 sophisticated use-cases than a framebuffer device can handle. At the
 moment basic functionality is supported with the intention to extend:
o multiple dynamically allocated/destroyed framebuffers
o buffers of arbitrary sizes
o better configuration options including multiple display support"
>>> Well, that's all stuff you had spelled out in the accompanying mail,
>>> but that's all items which could be taken care of by a protocol
>>> extension too.
>> of course
 I tried to evaluate what would it be like to extend existing fbif...
 It looks like having 2 different protocols in a single file.
>>> This is what I'd like you to expand on.
>> To start with:
>>
>> 1. In/out event sizes
>>  o fbif - 40 octets
>>  o displif - 40 octets
>> It fits now, but this is only the initial version of the displif protocol
>> which means that there could be requests which will not fit
>> (we are thinking of introducing some GPU related functionality
>> later on). In that case we cannot alter fbif sizes as we need to
>> be backward compatible an will be forced to handle those
>> apart of fbif. This makes me believe if we extend fbif it is better
>> to have separate structures/rings from the start.
>>
>> 2. Shared page
>> Displif doesn't use anything like struct xenfb_page, but
>> DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct 
>> xendispl_resp);
>> which I believe is a better and more common way.
>> Output events use a shared page which only has in_cons and in_prod
>> and all the rest is used for incoming events. Here struct xenfb_page
>> could probably be used as is despite the fact that it only has a half
>> of a page for incoming events which is only 50 events. (consider
>> something like 60Hz display)
>>
>> 3. Amount of changes.
>> fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
>> events, so it looks like it is easier to get fb support into displif
>> than vice versa. displif at the moment has 6 requests and 1 event,
>> multiple connector support, etc.
>> BTW, I can add framebuffer's update and resize into displif, so
>> it could  probably supersede fbif at some point
>>
 What is more fbif can be used together with displif running at the
 same time, e.g. on Linux one provides framebuffer and another DRM
>>> And this is certainly a valid argument (which hence should be
>>> spelled out in the description).
>> ok
>>> Jan
>>>
>>




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

Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

2017-01-26 Thread Oleksandr Andrushchenko 

On 01/27/2017 09:46 AM, Juergen Gross wrote:

On 27/01/17 08:21, Oleksandr Andrushchenko wrote:

On 01/27/2017 09:12 AM, Juergen Gross wrote:

Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.

Signed-off-by: Juergen Gross 
---
V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
---
   drivers/input/misc/xen-kbdfront.c | 15 ---
   1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c
b/drivers/input/misc/xen-kbdfront.c
index 3900875..3aae9b4 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -16,6 +16,7 @@
   #include 
   #include 
   #include 
+#include 
   #include 
   #include 
   @@ -108,7 +109,7 @@ static irqreturn_t input_handler(int rq, void
*dev_id)
   static int xenkbd_probe(struct xenbus_device *dev,
 const struct xenbus_device_id *id)
   {
-int ret, i;
+int ret, i, width, height;
   unsigned int abs;
   struct xenkbd_info *info;
   struct input_dev *kbd, *ptr;
@@ -173,9 +174,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
   ptr->id.product = 0xfffe;
 if (abs) {
+width = XENFB_WIDTH;
+height = XENFB_HEIGHT;
+#ifdef CONFIG_FB
+if (registered_fb[0]) {

This still will not help if FB gets registered after kbd+ptr

Hmm, so you think I should add a call to fb_register_client() to get
events for new registered framebuffer devices?

yes, but also pay attention to CONFIG_FB_NOTIFY: you may still
end up w/o notification.


This would probably work. I'll have a try.


Thanks,

Juergen

My bigger concern here is that we try to tie keyboard and pointer device
to the framebuffer. IMO, these are independent parts of the system and 
the relation
depends on the use-case. One can have graphics enabled w/o framebuffer 
at all, e.g.

DRM/KMS + OpenGLES + Weston + kbd + ptr...

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

Re: [Xen-devel] Xen on lager for DOMU

2017-01-26 Thread Oleksandr Andrushchenko 

On 01/26/2017 09:11 PM, Julien Grall wrote:



On 24/01/2017 13:05, George John wrote:

Hi all,


Hello,



I was able to bring up Dom0 in lager board by steps followed by charles.
What could be the steps I could follow to bring up DomU in xen for lager
board.?..


You can give a look to:
- https://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs
- 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#DomU_kernel_and_DTS


Alternatively, you can find a distribution where the kernel has Xen 
options enabled.

For testing and some development on ARM64 I use Ubuntu for DomU [2], [3]

It may be the case in Yocto, or you can look at centos (see [1]).

How to bring xen-utils in the filesystem(yocto build) of Dom0

linux for configuring DomU.


I don't know much about Yocto. I have CCed Iurri who I think is using 
Yocto. It might be able to help you here.


Cheers,

[1] https://blog.xenproject.org/2015/10/05/xen-in-centos-7-aarch64/


[2] https://github.com/xen-troops/manifests/wiki/DomU-Ubuntu-on-H3-M3
[3] https://help.ubuntu.com/community/Xen

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

Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

2017-01-26 Thread Juergen Gross 
On 27/01/17 08:21, Oleksandr Andrushchenko wrote:
> On 01/27/2017 09:12 AM, Juergen Gross wrote:
>> Instead of using the default resolution of 800*600 for the pointing
>> device of xen-kbdfront try to read the resolution of the (virtual)
>> framebuffer device. Use the default as fallback only.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>> V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
>> ---
>>   drivers/input/misc/xen-kbdfront.c | 15 ---
>>   1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/input/misc/xen-kbdfront.c
>> b/drivers/input/misc/xen-kbdfront.c
>> index 3900875..3aae9b4 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -16,6 +16,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   @@ -108,7 +109,7 @@ static irqreturn_t input_handler(int rq, void
>> *dev_id)
>>   static int xenkbd_probe(struct xenbus_device *dev,
>> const struct xenbus_device_id *id)
>>   {
>> -int ret, i;
>> +int ret, i, width, height;
>>   unsigned int abs;
>>   struct xenkbd_info *info;
>>   struct input_dev *kbd, *ptr;
>> @@ -173,9 +174,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>   ptr->id.product = 0xfffe;
>> if (abs) {
>> +width = XENFB_WIDTH;
>> +height = XENFB_HEIGHT;
>> +#ifdef CONFIG_FB
>> +if (registered_fb[0]) {
> This still will not help if FB gets registered after kbd+ptr

Hmm, so you think I should add a call to fb_register_client() to get
events for new registered framebuffer devices?

This would probably work. I'll have a try.


Thanks,

Juergen

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

Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

2017-01-26 Thread Oleksandr Andrushchenko 

On 01/27/2017 09:12 AM, Juergen Gross wrote:

Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.

Signed-off-by: Juergen Gross 
---
V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
---
  drivers/input/misc/xen-kbdfront.c | 15 ---
  1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875..3aae9b4 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -16,6 +16,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -108,7 +109,7 @@ static irqreturn_t input_handler(int rq, void *dev_id)

  static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
  {
-   int ret, i;
+   int ret, i, width, height;
unsigned int abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
@@ -173,9 +174,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
ptr->id.product = 0xfffe;
  
  	if (abs) {

+   width = XENFB_WIDTH;
+   height = XENFB_HEIGHT;
+#ifdef CONFIG_FB
+   if (registered_fb[0]) {

This still will not help if FB gets registered after kbd+ptr

+   width = registered_fb[0]->var.xres_virtual;
+   height = registered_fb[0]->var.yres_virtual;
+   }
+#endif
__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, width, 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, height, 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);



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

[Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront

2017-01-26 Thread Juergen Gross 
Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.

Signed-off-by: Juergen Gross 
---
V2: get framebuffer resolution only if CONFIG_FB (Dmitry Torokhov)
---
 drivers/input/misc/xen-kbdfront.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875..3aae9b4 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -108,7 +109,7 @@ static irqreturn_t input_handler(int rq, void *dev_id)
 static int xenkbd_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
-   int ret, i;
+   int ret, i, width, height;
unsigned int abs;
struct xenkbd_info *info;
struct input_dev *kbd, *ptr;
@@ -173,9 +174,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
ptr->id.product = 0xfffe;
 
if (abs) {
+   width = XENFB_WIDTH;
+   height = XENFB_HEIGHT;
+#ifdef CONFIG_FB
+   if (registered_fb[0]) {
+   width = registered_fb[0]->var.xres_virtual;
+   height = registered_fb[0]->var.yres_virtual;
+   }
+#endif
__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, width, 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, height, 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);
-- 
2.10.2


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

Re: [Xen-devel] [DOC v8] PV Calls protocol design

2017-01-26 Thread Oleksandr Andrushchenko 

Hi, Stefano!

 Error numbers

The numbers corresponding to the error names specified by POSIX are:

 [EPERM] -1
 [ENOENT]-2


Don't you want to use Xen's errno.h here as described in [1]?
So we have error codes consistent for all PV protocols?

Thanks,
Oleksandr

[1] https://marc.info/?l=xen-devel=148545604312317=2

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

Re: [Xen-devel] [PATCH] xen, input: try to read screen resolution for xen-kbdfront

2017-01-26 Thread Juergen Gross 
On 24/01/17 19:47, Dmitry Torokhov wrote:
> On Tue, Jan 24, 2017 at 01:09:55PM +0100, Juergen Gross wrote:
>> Instead of using the default resolution of 800*600 for the pointing
>> device of xen-kbdfront try to read the resolution of the (virtual)
>> framebuffer device. Use the default as fallback only.
>>
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Juergen Gross 
>> ---
>>  drivers/input/misc/xen-kbdfront.c | 15 ---
>>  1 file changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/input/misc/xen-kbdfront.c 
>> b/drivers/input/misc/xen-kbdfront.c
>> index 3900875..0032c81 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -16,6 +16,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -108,10 +109,11 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>>  static int xenkbd_probe(struct xenbus_device *dev,
>>const struct xenbus_device_id *id)
>>  {
>> -int ret, i;
>> +int ret, i, width, height;
>>  unsigned int abs;
>>  struct xenkbd_info *info;
>>  struct input_dev *kbd, *ptr;
>> +struct fb_info *fb0;
>>  
>>  info = kzalloc(sizeof(*info), GFP_KERNEL);
>>  if (!info) {
>> @@ -173,9 +175,16 @@ static int xenkbd_probe(struct xenbus_device *dev,
>>  ptr->id.product = 0xfffe;
>>  
>>  if (abs) {
>> +width = XENFB_WIDTH;
>> +height = XENFB_HEIGHT;
>> +fb0 = registered_fb[0];
> 
> This will break if !CONFIG_FBi I think. While i see that xen.config has
> it on I wonder if it is still possible to turn it off (either randconfig
> or intentionally).

kbuild robot says it is. :-(

Sending V2.


Thanks,

Juergen


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

[Xen-devel] [xen-unstable test] 104728: regressions - FAIL

2017-01-26 Thread osstest service owner 
flight 104728 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104728/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
104681
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-install   fail REGR. vs. 104681
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install   fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
104681
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 104681
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 104681
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install fail REGR. vs. 104681
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 104681
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
104681
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
104681
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 104681
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 104681

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

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-check

[Xen-devel] [xen-unstable-smoke test] 104737: tolerable trouble: broken/fail/pass - PUSHED

2017-01-26 Thread osstest service owner 
flight 104737 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104737/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ce7d99d69fb669110d346bda371306095f82d1e6
baseline version:
 xen  9b3a59c10d91a57975661686dbc08278b78ae1de

Last test of basis   104725  2017-01-26 18:01:14 Z0 days
Testing same since   104737  2017-01-27 02:01:43 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Tamas K Lengyel 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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 :

+ branch=xen-unstable-smoke
+ revision=ce7d99d69fb669110d346bda371306095f82d1e6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
ce7d99d69fb669110d346bda371306095f82d1e6
+ branch=xen-unstable-smoke
+ revision=ce7d99d69fb669110d346bda371306095f82d1e6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' xce7d99d69fb669110d346bda371306095f82d1e6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ :

Re: [Xen-devel] [PATCH v3] arm/p2m: Fix regression during domain shutdown with active mem_access

2017-01-26 Thread Stefano Stabellini 
On Wed, 25 Jan 2017, Julien Grall wrote:
> Hi Tamas,
> 
> On 25/01/2017 16:12, Tamas K Lengyel wrote:
> > The change in commit 438c5fe4f0c introduced a regression for domains where
> > mem_acces is or was active. When relinquish_p2m_mapping attempts to clear
> > a page where the order is not 0 the following ASSERT is triggered:
> > 
> > ASSERT(!p2m->mem_access_enabled || page_order == 0);
> > 
> > This regression was unfortunately not caught during testing in preparation
> > for the 4.8 release.
> > 
> > In this patch we adjust the ASSERT to not trip when the domain
> > is being shutdown.
> > 
> > Ideally this fix would be part of Xen 4.8.1.
> 
> +1 for the backport.
> 
> 
> > 
> > Signed-off-by: Tamas K Lengyel 
> 
> Acked-by: Julien Grall 
> 

Done

> 
> > ---
> > Cc: Stefano Stabellini 
> > Cc: Julien Grall 
> > 
> > v3: Minor adjustments
> > ---
> >  xen/arch/arm/p2m.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > index 09ceb378a5..7762f453f5 100644
> > --- a/xen/arch/arm/p2m.c
> > +++ b/xen/arch/arm/p2m.c
> > @@ -991,9 +991,10 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
> > 
> >  /*
> >   * The radix-tree can only work on 4KB. This is only used when
> > - * memaccess is enabled.
> > + * memaccess is enabled and during shutdown.
> >   */
> > -ASSERT(!p2m->mem_access_enabled || page_order == 0);
> > +ASSERT(!p2m->mem_access_enabled || page_order == 0 ||
> > +   p2m->domain->is_dying);
> >  /*
> >   * The access type should always be p2m_access_rwx when the mapping
> >   * is removed.
> > 
> 
> -- 
> Julien Grall
> 

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

[Xen-devel] [PATCH] xen/arm: flush icache as well when XEN_DOMCTL_cacheflush is issued

2017-01-26 Thread Tamas K Lengyel 
When the toolstack modifies memory of a running ARM VM it may happen
that the underlying memory of a current vCPU PC is changed. Without
flushing the icache the vCPU may continue executing stale instructions.

In this patch we introduce VA-based icache flushing macros. Also expose
the xc_domain_cacheflush through xenctrl.h.

Signed-off-by: Tamas K Lengyel 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: patch has been verified to solve stale icache issues on the
  HiKey platform.
---
 tools/libxc/include/xenctrl.h|  6 ++
 tools/libxc/xc_private.h |  3 ---
 xen/arch/arm/mm.c|  1 +
 xen/include/asm-arm/arm32/page.h |  3 +++
 xen/include/asm-arm/arm64/page.h |  3 +++
 xen/include/asm-arm/page.h   | 31 +++
 6 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 63c616ff6a..cb80a2b07c 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2720,6 +2720,12 @@ int xc_livepatch_revert(xc_interface *xch, char *name, 
uint32_t timeout);
 int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
 int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
 
+/*
+ * ARM only. Ensure cache coherency after memory modifications.
+ */
+int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
+ xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
+
 /* Compat shims */
 #include "xenctrl_compat.h"
 
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 97445ae1fe..fddebdc917 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -366,9 +366,6 @@ void bitmap_byte_to_64(uint64_t *lp, const uint8_t *bp, int 
nbits);
 /* Optionally flush file to disk and discard page cache */
 void discard_file_cache(xc_interface *xch, int fd, int flush);
 
-int xc_domain_cacheflush(xc_interface *xch, uint32_t domid,
-xen_pfn_t start_pfn, xen_pfn_t nr_pfns);
-
 #define MAX_MMU_UPDATES 1024
 struct xc_mmu {
 mmu_update_t updates[MAX_MMU_UPDATES];
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 99588a330d..43e5b3d9e2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -389,6 +389,7 @@ void flush_page_to_ram(unsigned long mfn)
 void *v = map_domain_page(_mfn(mfn));
 
 clean_and_invalidate_dcache_va_range(v, PAGE_SIZE);
+invalidate_icache_va_range(v, PAGE_SIZE);
 unmap_domain_page(v);
 }
 
diff --git a/xen/include/asm-arm/arm32/page.h b/xen/include/asm-arm/arm32/page.h
index ea4b312c70..10e5288d0f 100644
--- a/xen/include/asm-arm/arm32/page.h
+++ b/xen/include/asm-arm/arm32/page.h
@@ -19,6 +19,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
 : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to invalidate icache on register R (may be an inline asm 
operand) */
+#define __invalidate_icache_one(R) STORE_CP32(R, ICIMVAU)
+
 /* Inline ASM to invalidate dcache on register R (may be an inline asm 
operand) */
 #define __invalidate_dcache_one(R) STORE_CP32(R, DCIMVAC)
 
diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 23d778154d..0f380b95b4 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -16,6 +16,9 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
 : : "r" (pte.bits), "r" (p) : "memory");
 }
 
+/* Inline ASM to invalidate icache on register R (may be an inline asm 
operand) */
+#define __invalidate_icache_one(R) "ic ivau, %" #R ";"
+
 /* Inline ASM to invalidate dcache on register R (may be an inline asm 
operand) */
 #define __invalidate_dcache_one(R) "dc ivac, %" #R ";"
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index c492d6df50..a618d0e556 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -371,6 +371,37 @@ static inline int clean_and_invalidate_dcache_va_range
 : : "r" (_p), "m" (*_p));   \
 } while (0)
 
+static inline int invalidate_icache_va_range(const void *p, unsigned long size)
+{
+size_t off;
+const void *end = p + size;
+
+dsb(sy);   /* So the CPU issues all writes to the range */
+
+off = (unsigned long)p % cacheline_bytes;
+if ( off )
+{
+p -= off;
+asm volatile (__invalidate_icache_one(0) : : "r" (p));
+p += cacheline_bytes;
+size -= cacheline_bytes - off;
+}
+off = (unsigned long)end % cacheline_bytes;
+if ( off )
+{
+end -= off;
+size -= off;
+asm volatile (__invalidate_icache_one(0) : : "r" (end));
+}
+
+for ( ; p < end; p += cacheline_bytes )
+asm volatile (__invalidate_icache_one(0) : : "r" (p));
+
+dsb(sy);   /* So we know the

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

2017-01-26 Thread Dario Faggioli 
On Thu, 2017-01-26 at 13:59 -0500, Meng Xu wrote:
> Hi Dario,
> 
Hi,

> On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli
>  wrote:
> >
> >  Runqueue 0:
> >  CPU[00] runq=0, sibling=,0003, core=,00ff
> > run: [0.15] flags=2 cpu=0 credit=5804742 [w=256] load=3655
> > (~1%)
> >  CPU[01] runq=0, sibling=,0003, core=,00ff
> >  CPU[02] runq=0, sibling=,000c, core=,00ff
> > run: [0.3] flags=2 cpu=2 credit=6674856 [w=256] load=262144
> > (~100%)
> >  CPU[03] runq=0, sibling=,000c, core=,00ff
> >  RUNQ:
> 
> What is the difference between RUNQ and Runqueue 0 in the message?
> 
Right. So, this is more comprehensive output:

(XEN) [ 2797.156864] Cpupool 0:
(XEN) [ 2797.156866] Cpus: 0-5,10-15
(XEN) [ 2797.156868] Scheduler: SMP Credit Scheduler rev2 (credit2)
(XEN) [ 2797.156871] Active queues: 2
(XEN) [ 2797.156873]default-weight = 256
(XEN) [ 2797.156876] Runqueue 0:
(XEN) [ 2797.156878]ncpus  = 6
(XEN) [ 2797.156879]cpus   = 0-5
(XEN) [ 2797.156881]max_weight = 256
(XEN) [ 2797.156882]instload   = 5
(XEN) [ 2797.156884]aveload= 1052984 (~401%)
(XEN) [ 2797.156887]idlers: ,002a
(XEN) [ 2797.156889]tickled: ,
(XEN) [ 2797.156891]fully idle cores: ,
(XEN) [ 2797.156894] Runqueue 1:
(XEN) [ 2797.156896]ncpus  = 6
(XEN) [ 2797.156897]cpus   = 10-15
(XEN) [ 2797.156899]max_weight = 256
(XEN) [ 2797.156900]instload   = 4
(XEN) [ 2797.156902]aveload= 1061305 (~404%)
(XEN) [ 2797.156904]idlers: ,e800
(XEN) [ 2797.156906]tickled: ,
(XEN) [ 2797.156908]fully idle cores: ,c000
(XEN) [ 2797.156910] Domain info:
(XEN) [ 2797.156912]Domain: 0 w 256 v 16
(XEN) [ 2797.156914]  1: [0.0] flags=2 cpu=4 credit=-476120314 [w=256] 
load=85800 (~32%)
(XEN) [ 2797.156919]  2: [0.1] flags=0 cpu=2 credit=5630728 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.156923]  3: [0.2] flags=0 cpu=2 credit=4719251 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.156928]  4: [0.3] flags=2 cpu=2 credit=5648202 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.156933]  5: [0.4] flags=2 cpu=12 credit=2735243 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.156939]  6: [0.5] flags=2 cpu=12 credit=2721770 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.156945]  7: [0.6] flags=0 cpu=12 credit=2150753 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.156950]  8: [0.7] flags=0 cpu=14 credit=10424341 [w=256] 
load=2836 (~1%)
(XEN) [ 2797.156986]  9: [0.8] flags=0 cpu=4 credit=1050 [w=256] 
load=14 (~0%)
(XEN) [ 2797.156991] 10: [0.9] flags=0 cpu=14 credit=1050 [w=256] 
load=12 (~0%)
(XEN) [ 2797.156995] 11: [0.10] flags=0 cpu=5 credit=9204778 [w=256] 
load=7692 (~2%)
(XEN) [ 2797.156999] 12: [0.11] flags=0 cpu=1 credit=10501097 [w=256] 
load=2791 (~1%)
(XEN) [ 2797.157004] 13: [0.12] flags=0 cpu=4 credit=1050 [w=256] 
load=28 (~0%)
(XEN) [ 2797.157008] 14: [0.13] flags=0 cpu=11 credit=1050 [w=256] 
load=19 (~0%)
(XEN) [ 2797.157013] 15: [0.14] flags=0 cpu=14 credit=1050 [w=256] 
load=388 (~0%)
(XEN) [ 2797.157017] 16: [0.15] flags=0 cpu=3 credit=9832716 [w=256] 
load=7326 (~2%)
(XEN) [ 2797.157022]Domain: 1 w 256 v 2
(XEN) [ 2797.157024] 17: [1.0] flags=2 cpu=10 credit=-1085114190 [w=256] 
load=261922 (~99%)
(XEN) [ 2797.157029] 18: [1.1] flags=0 cpu=14 credit=1050 [w=256] 
load=0 (~0%)
(XEN) [ 2797.157033]Domain: 2 w 256 v 2
(XEN) [ 2797.157035] 19: [2.0] flags=2 cpu=0 credit=-593239186 [w=256] 
load=47389 (~18%)
(XEN) [ 2797.157040] 20: [2.1] flags=0 cpu=11 credit=1050 [w=256] 
load=0 (~0%)
(XEN) [ 2797.157044] Runqueue 0:
(XEN) [ 2797.157047] CPU[00] runq=0, sibling=,0003, 
core=,00ff
(XEN) [ 2797.157050]run: [2.0] flags=2 cpu=0 credit=-593239186 [w=256] 
load=47389 (~18%)
(XEN) [ 2797.157055] CPU[01] runq=0, sibling=,0003, 
core=,00ff
(XEN) [ 2797.157058] CPU[02] runq=0, sibling=,000c, 
core=,00ff
(XEN) [ 2797.157061]run: [0.3] flags=2 cpu=2 credit=5648202 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.157066] CPU[03] runq=0, sibling=,000c, 
core=,00ff
(XEN) [ 2797.157069] CPU[04] runq=0, sibling=,0030, 
core=,00ff
(XEN) [ 2797.157072]run: [0.0] flags=2 cpu=4 credit=-476120314 [w=256] 
load=85800 (~32%)
(XEN) [ 2797.157077] CPU[05] runq=0, sibling=,0030, 
core=,00ff
(XEN) [ 2797.157080] RUNQ:
(XEN) [ 2797.157081]  0: [0.1] flags=0 cpu=2 credit=5630728 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.157086]  1: [0.2] flags=0 cpu=2 credit=4719251 [w=256] 
load=262144 (~100%)
(XEN) [ 2797.157090] Runqueue 1:
(XEN) [ 2797.157093] CPU[10] runq=1,

[Xen-devel] CfP Virtualization in High-Performance Cloud Computing Workshop (VHPC '17)

2017-01-26 Thread VHPC 17 


CALL FOR PAPERS


12th Workshop on Virtualization in High­-Performance Cloud Computing  (VHPC
'17)

held in conjunction with the International Supercomputing Conference - High
Performance,

June 18-22, 2017, Frankfurt, Germany.

(Springer LNCS Proceedings)



Date: June 22, 2017

Workshop URL: http://vhpc.org

Abstract Submission Deadline: February 28, 2017

Paper Submission Deadline: April 25, 2017  (Springer LNCS)

Abstract/Paper Submission Link: https://edas.info/newPaper.php?c=23179



Call for Papers

Virtualization technologies constitute a key enabling factor for flexible
resource management

in modern data centers, and particularly in cloud environments. Cloud
providers need to

manage complex infrastructures in a seamless fashion to support the highly
dynamic and

heterogeneous workloads and hosted applications customers deploy.
Similarly, HPC

environments have been increasingly adopting techniques that enable
flexible management of

vast computing and networking resources, close to marginal provisioning
cost, which is

unprecedented in the history of scientific and commercial computing.

Various virtualization technologies contribute to the overall picture in
different ways: machine

virtualization, with its capability to enable consolidation of multiple
under­utilized servers with

heterogeneous software and operating systems (OSes), and its capability to
live­-migrate a

fully operating virtual machine (VM) with a very short downtime, enables
novel and dynamic

ways to manage physical servers; OS-­level virtualization (i.e.,
containerization), with its

capability to isolate multiple user­-space environments and to allow for
their co­existence within

the same OS kernel, promises to provide many of the advantages of machine
virtualization

with high levels of responsiveness and performance; I/O Virtualization
allows physical

NICs/HBAs to take traffic from multiple VMs or containers; network
virtualization, with its

capability to create logical network overlays that are independent of the
underlying physical

topology and IP addressing, provides the fundamental ground on top of which
evolved

network services can be realized with an unprecedented level of dynamicity
and flexibility; the

increasingly adopted paradigm of Software-­Defined Networking (SDN)
 promises to extend

this flexibility to the control and data planes of network paths.

Publication

Accepted papers will be published in a Springer LNCS proceedings volume.


Topics of Interest

The VHPC program committee solicits original, high-quality submissions
related to

virtualization across the entire software stack with a special focus on the
intersection of HPC

and the cloud.

Major Topics

- Virtualization in supercomputing environments, HPC clusters, HPC in the
cloud and grids
- OS-level virtualization and containers (Docker, rkt, Singularity,
Shifter, i.a.)
- Lightweight/specialized operating systems, unikernels
- Optimizations of virtual machine monitor platforms and hypervisors
- Hypervisor support for heterogenous resources (GPUs, co-processors,
FPGAs, etc.)
- Virtualization support for emerging memory technologies

- Virtualization in enterprise HPC and microvisors
- Software defined networks and network virtualization
- Management, deployment of virtualized environments and orchestration
(Kubernetes i.a.),
- Workflow-pipeline container-based composability
- Performance measurement, modelling and monitoring of virtualized/cloud
workloads
- Virtualization in data intensive computing and Big Data processing - HPC
convergence
- Adaptation of HPC technologies in the cloud (high performance networks,
RDMA, etc.)

- ARM-based hypervisors, ARM virtualization extensions
- I/O virtualization and cloud based storage systems

- GPU, FPGA and many-core accelerator virtualization
- Job scheduling/control/policy and container placement in virtualized
environments
- Cloud reliability, fault-tolerance and high-availability
- QoS and SLA in virtualized environments
- IaaS platforms, cloud frameworks and APIs

- Large-scale virtualization in domains such as finance and government
- Energy-efficient and power-aware virtualization

- Container security

- Configuration management tools for containers (including CFEngine,
Puppet, i.a.)

- Emerging topics including multi-kernel approaches and,NUMA in hypervisors




The Workshop on Virtualization in High­-Performance Cloud Computing (VHPC)
aims to

bring together researchers and industrial practitioners facing the
challenges

posed by virtualization in order to foster discussion, collaboration,
mutual exchange

of knowledge and experience, enabling research to ultimately provide novel

solutions for virtualized computing systems of tomorrow.

The workshop will be one day in length, composed of 20 min paper
presentations, each

followed by 10 min discussion

Re: [Xen-devel] [Qemu-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

2017-01-26 Thread Peter Maydell 
On 26 January 2017 at 20:47, Peter Maydell  wrote:
> On 26 January 2017 at 19:36, Stefano Stabellini  
> wrote:
>> It should be just a matter of replacing qdev_init_nofail with something
>> that can fail. I couldn't find a regular qdev_init that can return
>> error, so maybe we would need to add it.
>
> That's just
> object_property_set_bool(OBJECT(whatever), true, "realized", );
>
> ie "please realize the device".

(PS watch out for ownership refcounting issues depending on what
you did with parenting the device: you likely want to object_unparent()
and then object_unref() the thing in the error-exit path. See
qdev_device_add() for some example code, maybe.)

-- PMM

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

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

2017-01-26 Thread Julien Grall 

Hi,

On 26/01/2017 19:01, Boris Ostrovsky wrote:

On 01/26/2017 12:18 PM, Ian Jackson wrote:

Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684: regressions - 
FAIL"):

On 01/26/2017 08:23 AM, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254

...

I don't see why ARM tests fail. But then I also don't see (in the serial
log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
but there it nothing coming to the console from it.

Yes.

Unfortunately the osstest bisector is having some trouble with this
because the basis revision combination includes Xen f3a7ca02400d which
is ancient and doesn't build now on armhf, although it built before.
(I think the difference is that the compiler has been updated by
Debian.)

Since there is no output from Xen, I think this must be a problem with
the Xen image, not anything to do with Linux.

The history for this test is here:
  
http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus

In xen-unstable, there is what looks like a different failure:
  
http://logs.test-lab.xenproject.org/osstest/logs/104681/test-armhf-armhf-xl/serial-arndale-westfield.log

The machine in 104684 is cubietruck-metzinger which seems fine:
  
http://logs.test-lab.xenproject.org/osstest/results/host/cubietruck-metzinger.html


I am probably not interpreting  results correctly but 104684 looks like
failed to me:

http://logs.test-lab.xenproject.org/osstest/logs/104684/test-armhf-armhf-xl/info.html

And 104681's failure looks exactly like 104684.


I agree here. I think Ian got confused because the cubietruck is used to 
build Xen.




Here are the histories on the linux-linus and xen-unstable branches:
  
http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus
  
http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable

I think there may be a host-specific bug in ARM in xen-unstable ?


So the problem with linux-linus is the path in the DeviceTree for the 
serial has been changed by commit 5d99cc5 "ARM: dts: exynos: Move 
Exynos5250 and Exynos5420 nodes under soc". Before the path was 
/serial@12C2, now it is /soc/serial@12C2.


From my understanding, osstest is testing 3.18 and onwards. Correct?

If so, all the device tree we care have the same alias name to the 
serial node. I would use it to get avoid specific command line option 
depending on the kernel.


Replacing on xen command line "dtuart=/serial@12C2" by 
"dtuart=serial0" will allow Xen to be able to use again the console.


Regarding xen-unstable, I spot in the log a lot of "asix 2-3.2.4:1.0 
eth0: link down". So this looks like an ethernet issue. IIRC the network 
dongle on the Arndale has always been unreliable. So I would not worry 
too much here and wait the next flight.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [Qemu-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

2017-01-26 Thread Peter Maydell 
On 26 January 2017 at 19:36, Stefano Stabellini  wrote:
> It should be just a matter of replacing qdev_init_nofail with something
> that can fail. I couldn't find a regular qdev_init that can return
> error, so maybe we would need to add it.

That's just
object_property_set_bool(OBJECT(whatever), true, "realized", );

ie "please realize the device".

thanks
-- PMM

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

Re: [Xen-devel] [PATCH v1 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

2017-01-26 Thread Joao Martins 
On 01/26/2017 05:25 PM, Andy Lutomirski wrote:
> On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins  
> wrote:
>> This file defines an ABI shared between guest and hypervisor(s)
>> (KVM, Xen) and as such there should be an correspondent entry in
>> MAINTAINERS file. Notice that there's already a text notice at the
>> top of the header file, hence this commit simply enforces it more
>> explicitly and have both peers noticed when such changes happen.
>>
>> Signed-off-by: Joao Martins 
>> ---
>> This was suggested by folks at xen-devel as we missed some of the
>> ABI additions (e.g. flags field in pvti, TSC stable bit) - so this
>> patch is to help preventing that from happening. Alternatively I
>> could instead add a "PVCLOCK ABI" section in this file with the
>> two mailing lists.
> 
> If you do the latter, please add me as an R:.
OK, Thanks.

Since the ABI is used on both hypervisors I'll leave/wait for maintainers to
voice their preference.

Joao

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

Re: [Xen-devel] [PATCH v1 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

2017-01-26 Thread Joao Martins 
On 01/26/2017 05:25 PM, Andy Lutomirski wrote:
> On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins  
> wrote:
>> Right now there is only a pvclock_pvti_cpu0_va() which is defined
>> on kvmclock since:
>>
>> commit dac16fba6fc5
>> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
>>
>> The only user of this interface was kvm. This commit moves
>> pvclock_pvti_cpu0_va to pvclock which is a more generic place to have it
>> and adds the correspondent setter routine for it. This allows other
>> pvclock-based clocksources to use it, such as Xen.
> 
> With a minor nit:
> 
> Acked-by: Andy Lutomirski 
> 
>> +#else
>> +static inline void pvclock_set_pvti_cpu0_va(struct 
>> pvclock_vsyscall_time_info *pvti)
>> +{
>> +}
> 
> How about just not providing pvclock_set_pvti_cpu0_va() in this case?
> It'll save three lines of code, and, more importantly, it will force
> us to notice if we screw up the Kconfig stuff.
Sounds good, will remove this then. Thanks!

Joao

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

[Xen-devel] [PATCH v2 1/9] x86/boot/32: Convert the 32-bit pgtable setup code from assembly to C

2017-01-26 Thread Boris Ostrovsky 
The new Xen PVH entry point requires page tables to be setup by the
kernel since it is entered with paging disabled.

Pull the common code out of head_32.S so that mk_early_pgtbl_32() can be
invoked from both the new Xen entry point and the existing startup_32()
code.

Convert resulting common code to C.

Signed-off-by: Boris Ostrovsky 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: m...@codeblueprint.co.uk
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/1481215471-9639-1-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Ingo Molnar 
(cherry picked from commit 1e620f9b23e598ab936ece12233e98e97930b692)
---
This patch should go into mainline from x86 tree in 4.10 timeframe.

 arch/x86/include/asm/pgtable_32.h |  32 ++
 arch/x86/kernel/head32.c  |  62 +++
 arch/x86/kernel/head_32.S | 121 +++---
 3 files changed, 101 insertions(+), 114 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_32.h 
b/arch/x86/include/asm/pgtable_32.h
index b6c0b40..fbc7336 100644
--- a/arch/x86/include/asm/pgtable_32.h
+++ b/arch/x86/include/asm/pgtable_32.h
@@ -27,6 +27,7 @@
 
 extern pgd_t swapper_pg_dir[1024];
 extern pgd_t initial_page_table[1024];
+extern pmd_t initial_pg_pmd[];
 
 static inline void pgtable_cache_init(void) { }
 static inline void check_pgt_cache(void) { }
@@ -75,4 +76,35 @@ static inline void check_pgt_cache(void) { }
 #define kern_addr_valid(kaddr) (0)
 #endif
 
+/*
+ * This is how much memory in addition to the memory covered up to
+ * and including _end we need mapped initially.
+ * We need:
+ * (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE)
+ * (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE)
+ *
+ * Modulo rounding, each megabyte assigned here requires a kilobyte of
+ * memory, which is currently unreclaimed.
+ *
+ * This should be a multiple of a page.
+ *
+ * KERNEL_IMAGE_SIZE should be greater than pa(_end)
+ * and small than max_low_pfn, otherwise will waste some page table entries
+ */
+#if PTRS_PER_PMD > 1
+#define PAGE_TABLE_SIZE(pages) (((pages) / PTRS_PER_PMD) + PTRS_PER_PGD)
+#else
+#define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD)
+#endif
+
+/*
+ * Number of possible pages in the lowmem region.
+ *
+ * We shift 2 by 31 instead of 1 by 32 to the left in order to avoid a
+ * gas warning about overflowing shift count when gas has been compiled
+ * with only a host target support using a 32-bit type for internal
+ * representation.
+ */
+#define LOWMEM_PAGES 2<<31) - __PAGE_OFFSET) >> PAGE_SHIFT))
+
 #endif /* _ASM_X86_PGTABLE_32_H */
diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index f16c55b..e5fb436 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -49,3 +49,65 @@ asmlinkage __visible void __init i386_start_kernel(void)
 
start_kernel();
 }
+
+/*
+ * Initialize page tables.  This creates a PDE and a set of page
+ * tables, which are located immediately beyond __brk_base.  The variable
+ * _brk_end is set up to point to the first "safe" location.
+ * Mappings are created both at virtual address 0 (identity mapping)
+ * and PAGE_OFFSET for up to _end.
+ *
+ * In PAE mode initial_page_table is statically defined to contain
+ * enough entries to cover the VMSPLIT option (that is the top 1, 2 or 3
+ * entries). The identity mapping is handled by pointing two PGD entries
+ * to the first kernel PMD. Note the upper half of each PMD or PTE are
+ * always zero at this stage.
+ */
+void __init mk_early_pgtbl_32(void)
+{
+#ifdef __pa
+#undef __pa
+#endif
+#define __pa(x)  ((unsigned long)(x) - PAGE_OFFSET)
+   pte_t pte, *ptep;
+   int i;
+   unsigned long *ptr;
+   /* Enough space to fit pagetables for the low memory linear map */
+   const unsigned long limit = __pa(_end) +
+   (PAGE_TABLE_SIZE(LOWMEM_PAGES) << PAGE_SHIFT);
+#ifdef CONFIG_X86_PAE
+   pmd_t pl2, *pl2p = (pmd_t *)__pa(initial_pg_pmd);
+#define SET_PL2(pl2, val){ (pl2).pmd = (val); }
+#else
+   pgd_t pl2, *pl2p = (pgd_t *)__pa(initial_page_table);
+#define SET_PL2(pl2, val)   { (pl2).pgd = (val); }
+#endif
+
+   ptep = (pte_t *)__pa(__brk_base);
+   pte.pte = PTE_IDENT_ATTR;
+
+   while ((pte.pte & PTE_PFN_MASK) < limit) {
+
+   SET_PL2(pl2, (unsigned long)ptep | PDE_IDENT_ATTR);
+   *pl2p = pl2;
+#ifndef CONFIG_X86_PAE
+   /* Kernel PDE entry */
+   *(pl2p +  ((PAGE_OFFSET >> PGDIR_SHIFT))) = pl2;
+#endif
+   for (i = 0; i < PTRS_PER_PTE; i++) {
+

[Xen-devel] [PATCH v2 6/9] xen/pvh: Initialize grant table for PVH guests

2017-01-26 Thread Boris Ostrovsky 
Like PV guests, PVH does not have PCI devices and therefore cannot
use MMIO space to store grants. Instead it balloons out memory and
keeps grants there.

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* Updated commit message

 drivers/xen/grant-table.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index bb36b1e..d6786b8 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,13 +1146,13 @@ int gnttab_init(void)
 
 static int __gnttab_init(void)
 {
+   if (!xen_domain())
+   return -ENODEV;
+
/* Delay grant-table initialization in the PV on HVM case */
-   if (xen_hvm_domain())
+   if (xen_hvm_domain() && !xen_pvh_domain())
return 0;
 
-   if (!xen_pv_domain())
-   return -ENODEV;
-
return gnttab_init();
 }
 /* Starts after core_initcall so that xen_pvh_gnttab_setup can be called
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 4/9] xen/pvh: Bootstrap PVH guest

2017-01-26 Thread Boris Ostrovsky 
Start PVH guest at XEN_ELFNOTE_PHYS32_ENTRY address. Setup hypercall
page, initialize boot_params, enable early page tables.

Since this stub is executed before kernel entry point we cannot use
variables in .bss which is cleared by kernel. We explicitly place
variables that are initialized here into .data.

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* Assembly cleanup
* Check for e820 size in init_pvh_bootparams()
* Check XEN_HVM_START_MAGIC_VALUE in start_info


 arch/x86/xen/Kconfig |   2 +-
 arch/x86/xen/Makefile|   1 +
 arch/x86/xen/enlighten.c |  98 -
 arch/x86/xen/xen-pvh.S   | 137 +++
 include/xen/xen.h|   5 ++
 5 files changed, 241 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/xen/xen-pvh.S

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index c7b15f3..76b6dbd 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -53,5 +53,5 @@ config XEN_DEBUG_FS
 
 config XEN_PVH
bool "Support for running as a PVH guest"
-   depends on X86_64 && XEN && XEN_PVHVM
+   depends on XEN && XEN_PVHVM && ACPI
def_bool n
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index e47e527..cb0164a 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_XEN_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_XEN_DOM0) += vga.o
 obj-$(CONFIG_SWIOTLB_XEN)  += pci-swiotlb-xen.o
 obj-$(CONFIG_XEN_EFI)  += efi.o
+obj-$(CONFIG_XEN_PVH)  += xen-pvh.o
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 828f1b2..c82fe14 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -121,7 +122,8 @@
 DEFINE_PER_CPU(uint32_t, xen_vcpu_id);
 EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
 
-enum xen_domain_type xen_domain_type = XEN_NATIVE;
+enum xen_domain_type xen_domain_type
+   __attribute__((section(".data"))) = XEN_NATIVE;
 EXPORT_SYMBOL_GPL(xen_domain_type);
 
 unsigned long *machine_to_phys_mapping = (void *)MACH2PHYS_VIRT_START;
@@ -176,6 +178,17 @@ struct tls_descs {
  */
 static DEFINE_PER_CPU(struct tls_descs, shadow_tls_desc);
 
+#ifdef CONFIG_XEN_PVH
+/*
+ * PVH variables. These need to live in data segment since they are
+ * initialized before startup_{32|64}, which clear .bss, are invoked.
+ */
+bool xen_pvh __attribute__((section(".data"))) = 0;
+struct hvm_start_info pvh_start_info __attribute__((section(".data")));
+unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
+struct boot_params pvh_bootparams __attribute__((section(".data")));
+#endif
+
 static void clamp_max_cpus(void)
 {
 #ifdef CONFIG_SMP
@@ -1656,6 +1669,89 @@ asmlinkage __visible void __init xen_start_kernel(void)
 #endif
 }
 
+#ifdef CONFIG_XEN_PVH
+static void __init init_pvh_bootparams(void)
+{
+   struct xen_memory_map memmap;
+   unsigned int i;
+   int rc;
+
+   memset(_bootparams, 0, sizeof(pvh_bootparams));
+
+   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
+   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
+   rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
+   if (rc) {
+   xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
+   BUG();
+   }
+
+   if (memmap.nr_entries < E820MAX) {
+   pvh_bootparams.e820_map[memmap.nr_entries].addr =
+   ISA_START_ADDRESS;
+   pvh_bootparams.e820_map[memmap.nr_entries].size =
+   ISA_END_ADDRESS - ISA_START_ADDRESS;
+   pvh_bootparams.e820_map[memmap.nr_entries++].type =
+   E820_RESERVED;
+   } else
+   xen_raw_printk("Warning: Can fit ISA range into e820\n");
+
+   sanitize_e820_map(pvh_bootparams.e820_map,
+ ARRAY_SIZE(pvh_bootparams.e820_map),
+ _entries);
+
+   pvh_bootparams.e820_entries = memmap.nr_entries;
+   for (i = 0; i < pvh_bootparams.e820_entries; i++)
+   e820_add_region(pvh_bootparams.e820_map[i].addr,
+   pvh_bootparams.e820_map[i].size,
+   pvh_bootparams.e820_map[i].type);
+
+   pvh_bootparams.hdr.cmd_line_ptr =
+   pvh_start_info.cmdline_paddr;
+
+   /* The first module is always ramdisk. */
+   if (pvh_start_info.nr_modules) {
+   struct hvm_modlist_entry *modaddr =
+   __va(pvh_start_info.modlist_paddr);
+   pvh_bootparams.hdr.ramdisk_image = modaddr->paddr;
+   pvh_bootparams.hdr.ramdisk_size = modaddr->size;
+   }
+
+   /*
+* See Documentation/x86/boot.txt.
+*
+* Version 2.12 supports Xen entry point but we will use default x86/PC
+* environment (i.e. hardware_subarch 0).
+

[Xen-devel] [PATCH v2 8/9] xen/pvh: Enable CPU hotplug

2017-01-26 Thread Boris Ostrovsky 
PVH guests don't (yet) receive ACPI hotplug interrupts and therefore
need to monitor xenstore for CPU hotplug event.

Signed-off-by: Boris Ostrovsky 
---
 drivers/xen/cpu_hotplug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 5676aef..0bab60a3 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -107,7 +107,7 @@ static int __init setup_vcpu_hotplug_event(void)
.notifier_call = setup_cpu_watcher };
 
 #ifdef CONFIG_X86
-   if (!xen_pv_domain())
+   if (!xen_pv_domain() && !xen_pvh_domain())
 #else
if (!xen_domain())
 #endif
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 9/9] xen/pvh: Use Xen's emergency_restart op for PVH guests

2017-01-26 Thread Boris Ostrovsky 
Using native_machine_emergency_restart (called during reboot) will
lead PVH guests to machine_real_restart()  where we try to use
real_mode_header which is not initialized.

Signed-off-by: Boris Ostrovsky 
---
New in v2

 arch/x86/xen/enlighten.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 6463382..20ae5d9d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1915,6 +1915,9 @@ static void __init xen_hvm_guest_init(void)
x86_init.irqs.intr_init = xen_init_IRQ;
xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
+
+   if (xen_pvh_domain())
+   machine_ops.emergency_restart = xen_emergency_restart;
 #ifdef CONFIG_KEXEC_CORE
machine_ops.shutdown = xen_hvm_shutdown;
machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 7/9] xen/pvh: PVH guests always have PV devices

2017-01-26 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 arch/x86/xen/platform-pci-unplug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/platform-pci-unplug.c 
b/arch/x86/xen/platform-pci-unplug.c
index 90d1b83..33a783c 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -73,8 +73,8 @@ bool xen_has_pv_devices(void)
if (!xen_domain())
return false;
 
-   /* PV domains always have them. */
-   if (xen_pv_domain())
+   /* PV and PVH domains always have them. */
+   if (xen_pv_domain() || xen_pvh_domain())
return true;
 
/* And user has xen_platform_pci=0 set in guest config as
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 0/9] PVH v2 support (domU)

2017-01-26 Thread Boris Ostrovsky 
PVH v2 support for unprivileged guests.

Now that we decided to defer ACPI CPU hotplug until we understand better
what to do about it in dom0 I am sending v2 with PV-style CPU hotplug, with
v1 comments addressed.


Boris Ostrovsky (9):
  x86/boot/32: Convert the 32-bit pgtable setup code from assembly to C
  xen/x86: Remove PVH support
  xen/pvh: Import PVH-related Xen public interfaces
  xen/pvh: Bootstrap PVH guest
  xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC
  xen/pvh: Initialize grant table for PVH guests
  xen/pvh: PVH guests always have PV devices
  xen/pvh: Enable CPU hotplug
  xen/pvh: Use Xen's emergency_restart op for PVH guests

 arch/x86/include/asm/pgtable_32.h  |  32 
 arch/x86/kernel/head32.c   |  62 
 arch/x86/kernel/head_32.S  | 121 +--
 arch/x86/xen/Kconfig   |   2 +-
 arch/x86/xen/Makefile  |   1 +
 arch/x86/xen/enlighten.c   | 272 +
 arch/x86/xen/mmu.c |  21 +--
 arch/x86/xen/platform-pci-unplug.c |   4 +-
 arch/x86/xen/setup.c   |  37 +
 arch/x86/xen/smp.c |  78 --
 arch/x86/xen/smp.h |   8 -
 arch/x86/xen/xen-head.S|  62 +---
 arch/x86/xen/xen-ops.h |   1 -
 arch/x86/xen/xen-pvh.S | 137 +
 drivers/xen/cpu_hotplug.c  |   2 +-
 drivers/xen/events/events_base.c   |   1 -
 drivers/xen/grant-table.c  |   8 +-
 include/xen/interface/elfnote.h|  12 +-
 include/xen/interface/hvm/hvm_vcpu.h   | 143 +
 include/xen/interface/hvm/start_info.h |  98 
 include/xen/xen.h  |  12 +-
 21 files changed, 676 insertions(+), 438 deletions(-)
 create mode 100644 arch/x86/xen/xen-pvh.S
 create mode 100644 include/xen/interface/hvm/hvm_vcpu.h
 create mode 100644 include/xen/interface/hvm/start_info.h

-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 5/9] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC

2017-01-26 Thread Boris Ostrovsky 
Make sure they don't use these devices since they are not emulated
for unprivileged PVH guest.

Also don't initialize hypercall page for them in init_hvm_pv_info()
since this has already been done.

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* Use cpuid_ebx() instead of cpuid()

 arch/x86/xen/enlighten.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c82fe14..6463382 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1791,20 +1791,32 @@ void __ref xen_hvm_init_shared_info(void)
 static void __init init_hvm_pv_info(void)
 {
int major, minor;
-   uint32_t eax, ebx, ecx, edx, pages, msr, base;
-   u64 pfn;
+   uint32_t eax, ebx, ecx, edx, msr, base;
 
base = xen_cpuid_base();
-   cpuid(base + 1, , , , );
+   eax = cpuid_eax(base + 1);
 
major = eax >> 16;
minor = eax & 0x;
printk(KERN_INFO "Xen version %d.%d.\n", major, minor);
 
-   cpuid(base + 2, , , , );
+   xen_domain_type = XEN_HVM_DOMAIN;
 
-   pfn = __pa(hypercall_page);
-   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+   /* PVH set up hypercall page earlier in xen_prepare_pvh(). */
+   if (xen_pvh_domain()) {
+   pv_info.name = "Xen PVH";
+#ifdef CONFIG_ACPI
+   /* No PIC or IOAPIC */
+   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+#endif
+   } else {
+   u64 pfn;
+
+   pv_info.name = "Xen HVM";
+   msr = cpuid_ebx(base + 2);
+   pfn = __pa(hypercall_page);
+   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+   }
 
xen_setup_features();
 
@@ -1813,10 +1825,6 @@ static void __init init_hvm_pv_info(void)
this_cpu_write(xen_vcpu_id, ebx);
else
this_cpu_write(xen_vcpu_id, smp_processor_id());
-
-   pv_info.name = "Xen HVM";
-
-   xen_domain_type = XEN_HVM_DOMAIN;
 }
 #endif
 
@@ -1892,6 +1900,9 @@ static void __init xen_hvm_guest_init(void)
 
init_hvm_pv_info();
 
+   if (xen_pvh_domain())
+   x86_platform.legacy.rtc = 0;
+
xen_hvm_init_shared_info();
 
xen_panic_handler_init();
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 3/9] xen/pvh: Import PVH-related Xen public interfaces

2017-01-26 Thread Boris Ostrovsky 
Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 include/xen/interface/elfnote.h|  12 ++-
 include/xen/interface/hvm/hvm_vcpu.h   | 143 +
 include/xen/interface/hvm/start_info.h |  98 ++
 3 files changed, 252 insertions(+), 1 deletion(-)
 create mode 100644 include/xen/interface/hvm/hvm_vcpu.h
 create mode 100644 include/xen/interface/hvm/start_info.h

diff --git a/include/xen/interface/elfnote.h b/include/xen/interface/elfnote.h
index f90b034..9e9f9bf 100644
--- a/include/xen/interface/elfnote.h
+++ b/include/xen/interface/elfnote.h
@@ -193,9 +193,19 @@
 #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
 
 /*
+ * Physical entry point into the kernel.
+ *
+ * 32bit entry point into the kernel. When requested to launch the
+ * guest kernel in a HVM container, Xen will use this entry point to
+ * launch the guest in 32bit protected mode with paging disabled.
+ * Ignored otherwise.
+ */
+#define XEN_ELFNOTE_PHYS32_ENTRY 18
+
+/*
  * The number of the highest elfnote defined.
  */
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_SUPPORTED_FEATURES
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS32_ENTRY
 
 #endif /* __XEN_PUBLIC_ELFNOTE_H__ */
 
diff --git a/include/xen/interface/hvm/hvm_vcpu.h 
b/include/xen/interface/hvm/hvm_vcpu.h
new file mode 100644
index 000..32ca83e
--- /dev/null
+++ b/include/xen/interface/hvm/hvm_vcpu.h
@@ -0,0 +1,143 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2015, Roger Pau Monne 
+ */
+
+#ifndef __XEN_PUBLIC_HVM_HVM_VCPU_H__
+#define __XEN_PUBLIC_HVM_HVM_VCPU_H__
+
+#include "../xen.h"
+
+struct vcpu_hvm_x86_32 {
+uint32_t eax;
+uint32_t ecx;
+uint32_t edx;
+uint32_t ebx;
+uint32_t esp;
+uint32_t ebp;
+uint32_t esi;
+uint32_t edi;
+uint32_t eip;
+uint32_t eflags;
+
+uint32_t cr0;
+uint32_t cr3;
+uint32_t cr4;
+
+uint32_t pad1;
+
+/*
+ * EFER should only be used to set the NXE bit (if required)
+ * when starting a vCPU in 32bit mode with paging enabled or
+ * to set the LME/LMA bits in order to start the vCPU in
+ * compatibility mode.
+ */
+uint64_t efer;
+
+uint32_t cs_base;
+uint32_t ds_base;
+uint32_t ss_base;
+uint32_t es_base;
+uint32_t tr_base;
+uint32_t cs_limit;
+uint32_t ds_limit;
+uint32_t ss_limit;
+uint32_t es_limit;
+uint32_t tr_limit;
+uint16_t cs_ar;
+uint16_t ds_ar;
+uint16_t ss_ar;
+uint16_t es_ar;
+uint16_t tr_ar;
+
+uint16_t pad2[3];
+};
+
+/*
+ * The layout of the _ar fields of the segment registers is the
+ * following:
+ *
+ * Bits   [0,3]: type (bits 40-43).
+ * Bit4: s(descriptor type, bit 44).
+ * Bit[5,6]: dpl  (descriptor privilege level, bits 45-46).
+ * Bit7: p(segment-present, bit 47).
+ * Bit8: avl  (available for system software, bit 52).
+ * Bit9: l(64-bit code segment, bit 53).
+ * Bit   10: db   (meaning depends on the segment, bit 54).
+ * Bit   11: g(granularity, bit 55)
+ * Bits [12,15]: unused, must be blank.
+ *
+ * A more complete description of the meaning of this fields can be
+ * obtained from the Intel SDM, Volume 3, section 3.4.5.
+ */
+
+struct vcpu_hvm_x86_64 {
+uint64_t rax;
+uint64_t rcx;
+uint64_t rdx;
+uint64_t rbx;
+uint64_t rsp;
+uint64_t rbp;
+uint64_t rsi;
+uint64_t rdi;
+uint64_t rip;
+uint64_t rflags;
+
+uint64_t cr0;
+uint64_t cr3;
+uint64_t cr4;
+uint64_t efer;
+
+/*
+ * Using VCPU_HVM_MODE_64B implies that the vCPU is launched
+ * directly in long mode, so the cached parts of the segment
+ * registers get set to match that environment.
+ *
+ * If the user wants to launch the vCPU in compatibility mode
+

[Xen-devel] [PATCH v2 2/9] xen/x86: Remove PVH support

2017-01-26 Thread Boris Ostrovsky 
We are replacing existing PVH guests with new implementation.

We are keeping xen_pvh_domain() macro (for now set to zero) because
when we introduce new PVH implementation later in this series we will
reuse current PVH-specific code (xen_pvh_gnttab_setup()), and that
code is conditioned by 'if (xen_pvh_domain())'. (We will also need
a noop xen_pvh_domain() for !CONFIG_XEN_PVH).

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Juergen Gross 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Changes in v2:
* Added comment to commit message clarifying why xen_pvh_domain()
  is kept.


 arch/x86/xen/enlighten.c | 140 ++-
 arch/x86/xen/mmu.c   |  21 +-
 arch/x86/xen/setup.c |  37 +--
 arch/x86/xen/smp.c   |  78 --
 arch/x86/xen/smp.h   |   8 ---
 arch/x86/xen/xen-head.S  |  62 ++---
 arch/x86/xen/xen-ops.h   |   1 -
 drivers/xen/events/events_base.c |   1 -
 include/xen/xen.h|  13 +---
 9 files changed, 54 insertions(+), 307 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 51ef952..828f1b2 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1138,10 +1138,11 @@ void xen_setup_vcpu_info_placement(void)
xen_vcpu_setup(cpu);
}
 
-   /* xen_vcpu_setup managed to place the vcpu_info within the
-* percpu area for all cpus, so make use of it. Note that for
-* PVH we want to use native IRQ mechanism. */
-   if (have_vcpu_info_placement && !xen_pvh_domain()) {
+   /*
+* xen_vcpu_setup managed to place the vcpu_info within the
+* percpu area for all cpus, so make use of it.
+*/
+   if (have_vcpu_info_placement) {
pv_irq_ops.save_fl = __PV_IS_CALLEE_SAVE(xen_save_fl_direct);
pv_irq_ops.restore_fl = 
__PV_IS_CALLEE_SAVE(xen_restore_fl_direct);
pv_irq_ops.irq_disable = 
__PV_IS_CALLEE_SAVE(xen_irq_disable_direct);
@@ -1413,49 +1414,9 @@ static void __init xen_boot_params_init_edd(void)
  * Set up the GDT and segment registers for -fstack-protector.  Until
  * we do this, we have to be careful not to call any stack-protected
  * function, which is most of the kernel.
- *
- * Note, that it is __ref because the only caller of this after init
- * is PVH which is not going to use xen_load_gdt_boot or other
- * __init functions.
  */
-static void __ref xen_setup_gdt(int cpu)
+static void xen_setup_gdt(int cpu)
 {
-   if (xen_feature(XENFEAT_auto_translated_physmap)) {
-#ifdef CONFIG_X86_64
-   unsigned long dummy;
-
-   load_percpu_segment(cpu); /* We need to access per-cpu area */
-   switch_to_new_gdt(cpu); /* GDT and GS set */
-
-   /* We are switching of the Xen provided GDT to our HVM mode
-* GDT. The new GDT has  __KERNEL_CS with CS.L = 1
-* and we are jumping to reload it.
-*/
-   asm volatile ("pushq %0\n"
- "leaq 1f(%%rip),%0\n"
- "pushq %0\n"
- "lretq\n"
- "1:\n"
- : "=" (dummy) : "0" (__KERNEL_CS));
-
-   /*
-* While not needed, we also set the %es, %ds, and %fs
-* to zero. We don't care about %ss as it is NULL.
-* Strictly speaking this is not needed as Xen zeros those
-* out (and also MSR_FS_BASE, MSR_GS_BASE, MSR_KERNEL_GS_BASE)
-*
-* Linux zeros them in cpu_init() and in secondary_startup_64
-* (for BSP).
-*/
-   loadsegment(es, 0);
-   loadsegment(ds, 0);
-   loadsegment(fs, 0);
-#else
-   /* PVH: TODO Implement. */
-   BUG();
-#endif
-   return; /* PVH does not need any PV GDT ops. */
-   }
pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry_boot;
pv_cpu_ops.load_gdt = xen_load_gdt_boot;
 
@@ -1466,59 +1427,6 @@ static void __ref xen_setup_gdt(int cpu)
pv_cpu_ops.load_gdt = xen_load_gdt;
 }
 
-#ifdef CONFIG_XEN_PVH
-/*
- * A PV guest starts with default flags that are not set for PVH, set them
- * here asap.
- */
-static void xen_pvh_set_cr_flags(int cpu)
-{
-
-   /* Some of these are setup in 'secondary_startup_64'. The others:
-* X86_CR0_TS, X86_CR0_PE, X86_CR0_ET are set by Xen for HVM guests
-* (which PVH shared codepaths), while X86_CR0_PG is for PVH. */
-   write_cr0(read_cr0() | X86_CR0_MP | X86_CR0_NE | X86_CR0_WP | 
X86_CR0_AM);
-
-   if (!cpu)
-   return;
-   /*
-* For BSP, PSE PGE are set in probe_page_size_mask(), for APs
-* set them here. For all, OSFXSR

Re: [Xen-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

2017-01-26 Thread Stefano Stabellini 
On Thu, 26 Jan 2017, Roger Pau Monné wrote:
> On Wed, Jan 25, 2017 at 11:05:29AM +, Roger Pau Monné wrote:
> > On Tue, Jan 24, 2017 at 01:30:02PM -0800, Stefano Stabellini wrote:
> > > On Tue, 24 Jan 2017, Stefano Stabellini wrote:
> > > > On Tue, 24 Jan 2017, Roger Pau Monné wrote:
> > > > > Hello,
> > > > > 
> > > > > The following commit:
> > > > > 
> > > > > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894
> > > > > Author: Juergen Gross 
> > > > > Date:   Tue Nov 22 07:10:58 2016 +0100
> > > > > 
> > > > > xen: create qdev for each backend device
> > > > > 
> > > > > Prevents me from running QEMU on FreeBSD/Xen, the following is 
> > > > > printed on the
> > > > > QEMU log:
> > > > > 
> > > > > char device redirected to /dev/pts/2 (label serial0)
> > > > > xen be core: xen be core: can't open gnttab device
> > > > > can't open gnttab device
> > > > > xen be core: xen be core: can't open gnttab device
> > > > > can't open gnttab device
> > > > > 
> > > > > # xl create -c ~/domain.cfg
> > > > > Parsing config from /root/domain.cfg
> > > > > libxl: error: libxl_dm.c:2201:device_model_spawn_outcome: Domain 
> > > > > 32:domain 32 device model: spawn failed (rc=-3)
> > > > > libxl: error: libxl_create.c:1506:domcreate_devmodel_started: Domain 
> > > > > 32:device model did not start: -3
> > > > > libxl: error: libxl_dm.c:2315:kill_device_model: Device Model already 
> > > > > exited
> > > > > libxl: error: libxl.c:1572:libxl__destroy_domid: Domain 
> > > > > 32:Non-existant domain
> > > > > libxl: error: libxl.c:1531:domain_destroy_callback: Domain 32:Unable 
> > > > > to destroy guest
> > > > > libxl: error: libxl.c:1458:domain_destroy_cb: Domain 32:Destruction 
> > > > > of domain failed
> > > > > # cat /var/log/xen/qemu-dm-domain.log
> > > > > char device redirected to /dev/pts/2 (label serial0)
> > > > > xen be core: xen be core: can't open gnttab device
> > > > > can't open gnttab device
> > > > > xen be core: xen be core: can't open gnttab device
> > > > > can't open gnttab device
> > > > > 
> > > > > I'm not really familiar with any of that code, but I think that using
> > > > > qdev_init_nofail is wrong, since on FreeBSD/Xen for example we don't 
> > > > > yet
> > > > > support the gnttab device, so initialization of the Xen Qdisk backend 
> > > > > can fail
> > > > > (and possibly the same applies to Linux if someone decides to compile 
> > > > > a kernel
> > > > > without the gnttab device). Yet QEMU can be used without the Qdisk 
> > > > > backend.
> > > > 
> > > > How did you manage to configure QEMU before? The configure script had
> > > > xc_gnttab_open calls in it up to Xen 4.6.
> > > 
> > > I know the answer! Because the configure script only compiles the code,
> > > doesn't try to run it. xc_gnttab_open compiled correctly but returned
> > > error when executed. Is that right?
> > 
> > Yes, I'm quite that's right. FreeBSD is using gnttab_unimp.c, which 
> > implements
> > xengnttab_open, so compilation will not fail.
> > 
> > > 
> > > 
> > > > I am happy to support a use case where the kernel doesn't have gntdev,
> > > > but it needs to be explicit: we need to detect it in the configure
> > > > script, then avoid the initialization of devices which require it.
> > > 
> > > I would still prefer configure to be able to detect this case. If it
> > > cannot be made to detect it, then we can try to figure out a way to
> > > catch the initialization errors at run time. 
> > 
> > I think it's better to simply fail to initialize Xen Qdisk at runtime, or 
> > else
> > a xen-tools/QEMU compiled on a non-Xen environment won't get gnttab and as a
> > consequence Xen Qdisk support enabled, and I think it's quite common for
> > distros to compile Xen packages on non-Xen environments (where 
> > /dev/xen/gnttab
> > is not available).
> 
> Ping?

Sorry for the delay. Obviously, you are correct.


> I'm not really sure how to solve this because I have zero experience with QEMU
> internals (all this qdev stuff). Can we restore the previous behavior, where
> the failure to initialize a device wouldn't prevent QEMU from starting?

I am convinced that we need to be able to handle the initialization
errors at run time, but I would prefer not to revert
3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894.

It should be just a matter of replacing qdev_init_nofail with something
that can fail. I couldn't find a regular qdev_init that can return
error, so maybe we would need to add it.

Juergen, would you be up for coming up with a patch?___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 104725: tolerable trouble: broken/fail/pass - PUSHED

2017-01-26 Thread osstest service owner 
flight 104725 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104725/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  9b3a59c10d91a57975661686dbc08278b78ae1de
baseline version:
 xen  c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc

Last test of basis   104630  2017-01-24 19:01:56 Z2 days
Failing since104642  2017-01-25 10:01:54 Z1 days   30 attempts
Testing same since   104725  2017-01-26 18:01:14 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Dario Faggioli 
  Elena Ufimtseva 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Paul Lai 
  Praveen Kumar 
  Roger Pau Monne 
  Roger Pau Monné 
  Tim Deegan 
  Venu Busireddy 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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 :

+ branch=xen-unstable-smoke
+ revision=9b3a59c10d91a57975661686dbc08278b78ae1de
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
9b3a59c10d91a57975661686dbc08278b78ae1de
+ branch=xen-unstable-smoke
+ revision=9b3a59c10d91a57975661686dbc08278b78ae1de
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x9b3a59c10d91a57975661686dbc08278b78ae1de = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;

Re: [Xen-devel] Xen installation on Nvidia Jetson TK-1

2017-01-26 Thread Julien Grall 

On 24/01/2017 05:48, Methuku Karthik wrote:

Hello,


Hello,

Please don't use HTML in your e-mail. Plain text is the standard on 
mailing list.




I am trying to install xen on Nvidia Jetson TK1. I am using this repo

/git://xenbits.xen.org/people/ianc/xen.git
 branch : tegra-tk1-jetson-v1/


I would recommend you to try the patch series posted on the mailing list 
few months ago (see [1]).


If you still have any issue please report it on Xen-devel so it can be 
fixed on the new version of the series.




I tried
/make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson XEN_TARGET_ARCH=arm32
to build using this command

/

/but it doesnt work. instead i used

//make dist-xen debug=y CONFIG_EARLY_PRINTK=*tegra* XEN_TARGET_ARCH=arm32/

build was successful.


I checked Rules.mk file in xen/arch/arm there is no rule for 
CONFIG_EARLY_PRINTK= jetson or tegra ?


Looking at the series on the ML, it should be CONFIG_EARLY_PRINTK=tegra.

Regards,

[1] https://lists.xen.org/archives/html/xen-devel/2016-09/msg00386.html


--
Julien Grall

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

Re: [Xen-devel] Xen on lager for DOMU

2017-01-26 Thread Julien Grall 



On 24/01/2017 13:05, George John wrote:

Hi all,


Hello,



I was able to bring up Dom0 in lager board by steps followed by charles.
What could be the steps I could follow to bring up DomU in xen for lager
board.?..


You can give a look to:
- https://wiki.xen.org/wiki/Mainline_Linux_Kernel_Configs
	- 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions#DomU_kernel_and_DTS


Alternatively, you can find a distribution where the kernel has Xen 
options enabled. It may be the case in Yocto, or you can look at centos 
(see [1]).


How to bring xen-utils in the filesystem(yocto build) of Dom0

linux for configuring DomU.


I don't know much about Yocto. I have CCed Iurri who I think is using 
Yocto. It might be able to help you here.


Cheers,

[1] https://blog.xenproject.org/2015/10/05/xen-in-centos-7-aarch64/

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section

2017-01-26 Thread Thomas Garnier 
On Thu, Jan 26, 2017 at 10:52 AM, Andy Lutomirski  wrote:
> On Thu, Jan 26, 2017 at 8:59 AM, Thomas Garnier  wrote:
>> Each processor holds a GDT in its per-cpu structure. The sgdt
>> instruction gives the base address of the current GDT. This address can
>> be used to bypass KASLR memory randomization. With another bug, an
>> attacker could target other per-cpu structures or deduce the base of
>> the main memory section (PAGE_OFFSET).
>>
>> This patch relocates the GDT table for each processor inside the
>> Fixmap section. The space is reserved based on number of supported
>> processors.
>>
>> For consistency, the remapping is done by default on 32 and 64 bit.
>>
>> Each processor switches to its remapped GDT at the end of
>> initialization. For hibernation, the main processor returns with the
>> original GDT and switches back to the remapping at completion.
>>
>> This patch was tested on both architectures. Hibernation and KVM were
>> both tested specially for their usage of the GDT.
>
> I like this version much better.  Thanks!

Thanks for the feedback! I like this version better too.

>
> --Andy



-- 
Thomas

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

[Xen-devel] [xen-4.4-testing baseline-only test] 68467: tolerable FAIL

2017-01-26 Thread Platform Team regression test user 
This run is configured for baseline tests only.

flight 68467 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68467/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-5  20 xtf/test-hvm32-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-5 32 xtf/test-hvm32pae-invlpg~shadow fail baseline 
untested
 test-xtf-amd64-amd64-5  43 xtf/test-hvm64-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-4   53 leak-check/checkfail baseline untested
 test-amd64-amd64-xl19 guest-start/debian.repeat fail baseline untested
 test-xtf-amd64-amd64-3   53 leak-check/checkfail baseline untested
 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail baseline untested
 test-xtf-amd64-amd64-2   53 leak-check/checkfail baseline untested
 test-xtf-amd64-amd64-1   53 leak-check/checkfail baseline untested
 test-xtf-amd64-amd64-5   53 leak-check/checkfail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop  fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail baseline untested
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-xsa-195   fail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-xsa-195   fail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  394ddc2de62cbcaf9d28cc7373fde175e6ba3a5d

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-xtf-amd64-amd64-1

Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps

2017-01-26 Thread Tamas K Lengyel 
On Thu, Jan 26, 2017 at 10:54 AM, Tamas K Lengyel
 wrote:
> On Thu, Jan 26, 2017 at 4:30 AM, Julien Grall  wrote:
>> (CC xen-devel, Ravzan, and Stefao)
>>
>> Hi Tamas,
>>
>> Not sure why you only CC me on the answer. I have CCed again xen-devel as I
>> don't see any sensible discussion in it.
>>
>> On 26/01/2017 00:11, Tamas K Lengyel wrote:
>>>
>>> On Wed, Jan 25, 2017 at 3:41 PM, Julien Grall 
>>> wrote:

 Hi Tamas,

 On 25/01/2017 20:02, Tamas K Lengyel wrote:
>
>
> During an SMC trap it is possible that the user may change the memory



 By user, do you mean the monitor application?
>>>
>>>
>>> Yes.
>>
>>
>> It would be worth clarifying in the commit message.
>>
>>
>>>

> from where the SMC was fetched. However, without flushing the icache
> the SMC may still trigger if the pCPU was idle during the trap. Flush
> the icache to ensure consistency.



 invalidate_icache will invalidate the cache to PoU on all the pCPUs. But
 here you only mention a problem on the current pCPU. So which behavior do
 you want to achieve?
>>>
>>>
>>> It would be sufficient to flush the icache on the specific pCPU that
>>> trapped with the SMC. Didn't see anything defined in Xen to achieve
>>> that.
>>>

>
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Razvan Cojocaru 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> ---
>  xen/arch/arm/monitor.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c
> index 59ce8f635f..ae1b97993f 100644
> --- a/xen/arch/arm/monitor.c
> +++ b/xen/arch/arm/monitor.c
> @@ -63,6 +63,9 @@ int monitor_smc(void)
>  .reason = VM_EVENT_REASON_PRIVILEGED_CALL
>  };
>
> +/* Nuke the icache as the memory may get changed underneath us. */
> +invalidate_icache();
> +



 Can you explain why you put this call before the monitor trap and not
 after?
 From my understanding the monitoring application may change the memory.
 But
 by the time you modify the instruction, the instruction cache may have
 prefetched the previous instruction. So the problem is still there.
>>>
>>>
>>> Not sure how would that happen exactly? The vCPU gets paused until the
>>> user responds to the vm_event request, so where would it perform the
>>> prefetch again? Also, with this change I've verified that the repeated
>>> SMC issue no longer presents itself (it has been triggered quite
>>> regularly on the hikey before).
>>
>>
>> The ARM ARM provides a set of expected behavior and where to call the cache
>> maintenance instruction. If it is not done correctly, it may not affect your
>> platform but at some point in the future (or even already today) it will
>> break a platform. I wish you good luck to debug that when it happens. It is
>> a really nightmare :).
>>
>> So what I care the most is what is the correct behavior based on the ARM
>> ARM. A good overview can be found in a talk made by Mark Rutland [1].
>>
>> What I was concerned about is the instruction cache been shared between
>> multiple processors (for instance L2 cache or higher). A vCPU could also get
>> rescheduled to another processor afterwards. Leading to accessing an out of
>> date instruction cache.
>
>  I see, yea, in that case the instruction may still trigger regardless. Sigh.
>
>>
>>>
>>> Also, for multi-vCPU guest another vCPU fetching the SMC before the
>>> memory modification happen (ie. just after this flush) is not a
>>> problem and is expected behavior. Providing a non-racy setup for
>>> trapping on multi-vCPU guests requires other work (like altp2m).
>>
>>
>> I am not that concerned about the SMC itself, but the fact that you may
>> modify the guest memory whilst it is running. So another vCPU may end up to
>> execute a mix between new and old instructions depending of the state of its
>> instruction cache. That would result to a potential undefined behavior.
>>
>> Also, you want to make sure that if you write another SMC in memory, it is
>> effectively affecting all the vCPUs now and not a moment after.
>
> Yeap.
>
>>
>> So I still think the invalidate_icache should be done afterwards. IHMO
>> modifying guest instructions while other vCPU are running is very fragile as
>> other thread may execute the instructions your are running.
>
> I see your point, just got confused because the return from
> monitor_traps is not the return from the user. That just sends off the
> notification to the user. The actual return happens elsewhere once the
> user replies. That would be the point where the flush should happen.
>
>>
>>>

 Furthermore, the instruction cache may not snoop the data cache. So you
 have

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

2017-01-26 Thread Boris Ostrovsky 
On 01/26/2017 12:18 PM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684: 
> regressions - FAIL"):
>> On 01/26/2017 08:23 AM, osstest service owner wrote:
>>> flight 104684 linux-linus real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/104684/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
> ...
>> I don't see why ARM tests fail. But then I also don't see (in the serial
>> log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
>> but there it nothing coming to the console from it.
> Yes.
>
> Unfortunately the osstest bisector is having some trouble with this
> because the basis revision combination includes Xen f3a7ca02400d which
> is ancient and doesn't build now on armhf, although it built before.
> (I think the difference is that the compiler has been updated by
> Debian.)
>
> Since there is no output from Xen, I think this must be a problem with
> the Xen image, not anything to do with Linux.
>
> The history for this test is here:
>   
> http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus
>
> In xen-unstable, there is what looks like a different failure:
>   
> http://logs.test-lab.xenproject.org/osstest/logs/104681/test-armhf-armhf-xl/serial-arndale-westfield.log
>
> The machine in 104684 is cubietruck-metzinger which seems fine:
>   
> http://logs.test-lab.xenproject.org/osstest/results/host/cubietruck-metzinger.html

I am probably not interpreting  results correctly but 104684 looks like
failed to me:

http://logs.test-lab.xenproject.org/osstest/logs/104684/test-armhf-armhf-xl/info.html

And 104681's failure looks exactly like 104684.


>
> Here are the histories on the linux-linus and xen-unstable branches:
>   
> http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus
>   
> http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable
>
> I think there may be a host-specific bug in ARM in xen-unstable ?

I am not aware of any but I wouldn't know anyway.

-boris

>
>> There is output from 3.16 kernels though.
> I think the 3.16 tests you are refrring to are running with a
> different version of Xen and on different hardware.
>
> Ian.



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

Re: [Xen-devel] [PATCH] xen: sched: improve debug dump output.

2017-01-26 Thread Meng Xu 
Hi Dario,

I'm commenting on the rtds part.

On Thu, Jan 26, 2017 at 11:52 AM, Dario Faggioli
 wrote:
> Scheduling information debug dump for Credit2 is hard
> to read as it contains the same information repeated
> multiple time in different ways.
>
> In fact, in Credit2, CPUs are grouped in runqueus.
> Here's the current debug output:
>
>  CPU[00]  sibling=,0003, core=,00ff
> run: [32767.0] flags=0 cpu=0 credit=-1073741824 [w=0] load=0 (~0%)
>   1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
>   2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)
>  CPU[01]  sibling=,0003, core=,00ff
> run: [32767.1] flags=0 cpu=1 credit=-1073741824 [w=0] load=0 (~0%)
>   1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
>   2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)
>  CPU[02]  sibling=,000c, core=,00ff
> run: [0.2] flags=2 cpu=2 credit=3556909 [w=256] load=262144 (~100%)
>   1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
>   2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)
>
> Here, CPUs 0, 1 and 2, are all part of runqueue 0,
> the content of which (which, BTW, is d0v3 and d0v4)
> is printed 3 times! It is also not very useful to
> see the details of the idle vcpus, as they're always
> the same (except for the vCPU ids).
>
> With this change, we print:
>  - pCPUs details and, for non idle ones, what vCPU
>they're running;
>  - the runqueue content, once and for all.
>
>  Runqueue 0:
>  CPU[00] runq=0, sibling=,0003, core=,00ff
> run: [0.15] flags=2 cpu=0 credit=5804742 [w=256] load=3655 (~1%)
>  CPU[01] runq=0, sibling=,0003, core=,00ff
>  CPU[02] runq=0, sibling=,000c, core=,00ff
> run: [0.3] flags=2 cpu=2 credit=6674856 [w=256] load=262144 (~100%)
>  CPU[03] runq=0, sibling=,000c, core=,00ff
>  RUNQ:

What is the difference between RUNQ and Runqueue 0 in the message?

>   0: [0.1] flags=0 cpu=2 credit=6561215 [w=256] load=262144 (~100%)
>   1: [0.2] flags=0 cpu=2 credit=5812356 [w=256] load=262144 (~100%)
>
> Stop printing details of idle vCPUs also in Credit1
> and RTDS (they're pretty useless in there too).
>
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> Cc: Meng Xu 
> ---
>  xen/common/sched_credit.c  |6 ++--
>  xen/common/sched_credit2.c |   72 
> +---
>  xen/common/sched_rt.c  |9 +-
>  xen/common/schedule.c  |7 ++--
>  4 files changed, 49 insertions(+), 45 deletions(-)
>

> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 24b4b22..f2d979c 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -320,10 +320,17 @@ static void
>  rt_dump_pcpu(const struct scheduler *ops, int cpu)
>  {
>  struct rt_private *prv = rt_priv(ops);
> +struct rt_vcpu *svc;
>  unsigned long flags;
>
>  spin_lock_irqsave(>lock, flags);
> -rt_dump_vcpu(ops, rt_vcpu(curr_on_cpu(cpu)));
> +printk("CPU[%02d]\n", cpu);

We probably do not need this printk().
In rt_dump_vcpu(), we will print out the CPU number.

> +/* current VCPU (nothing to say if that's the idle vcpu). */
> +svc = rt_vcpu(curr_on_cpu(cpu));
> +if ( svc && !is_idle_vcpu(svc->vcpu) )
> +{
> +rt_dump_vcpu(ops, svc);
> +}

Maybe it is better to print the CPU number if the CPU is running an idle VCPU.
The printk info could be:
 printk("CPU[%02d]: idle\n", cpu);

>  spin_unlock_irqrestore(>lock, flags);
>  }

Thanks,

Meng


Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section

2017-01-26 Thread Andy Lutomirski 
On Thu, Jan 26, 2017 at 8:59 AM, Thomas Garnier  wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu structures or deduce the base of
> the main memory section (PAGE_OFFSET).
>
> This patch relocates the GDT table for each processor inside the
> Fixmap section. The space is reserved based on number of supported
> processors.
>
> For consistency, the remapping is done by default on 32 and 64 bit.
>
> Each processor switches to its remapped GDT at the end of
> initialization. For hibernation, the main processor returns with the
> original GDT and switches back to the remapping at completion.
>
> This patch was tested on both architectures. Hibernation and KVM were
> both tested specially for their usage of the GDT.

I like this version much better.  Thanks!

--Andy

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

Re: [Xen-devel] POSIX error names and codes in PV protocols

2017-01-26 Thread Oleksandr Andrushchenko 



On 01/26/2017 08:16 PM, Roger Pau Monné wrote:

On Thu, Jan 26, 2017 at 08:14:10PM +0200, Oleksandr Andrushchenko wrote:

On 01/26/2017 07:38 PM, Roger Pau Monné wrote:

On Thu, Jan 26, 2017 at 07:28:44PM +0200, Oleksandr Andrushchenko wrote:

On 01/26/2017 05:44 PM, Jan Beulich wrote:

On 26.01.17 at 15:40,  wrote:

There is some work happening on new PV protocols: sndif [1],

displif [2], PV calls [3] and the common part of those is that

error/status codes must be returned as a part of a response packet.

For that Konrad suggested [1] (and Stefano already used in [3]) POSIX

to be employed here instead of defining protocol specific error codes.

The problem I see here is that POSIX only defines names of the errors,

but not values [4]. So, in order to use POSIX one still needs to define

the values (names must be the same, but values may differ for different
OSes).

So, the question is what would be the best option to

a) have those numbers defined in OS agnostic way

b) have those defined for all PV protocols

Stefano has already defined the error code values in his work [3],

but for other protocols this should be reimplemented again.

Aren't these simply what public/errno.h provides? Why would any
Xen specific protocol want to define their own, now that we have
this base set?

Jan

Indeed, thank you
The problem is that it is not exposed to Linux, but I can see it
in FreeBSD [1] and the helper to convert error codes [2] there as well.
Is there any reason these are not available in Linux?

Xen error codes are Linux error codes, so I guess there's basically no need to
use them on Linux (although it would be good, just so that people is aware that
Xen and Linux are in different theoretical spaces, which happen to match in
Linux's case).

Roger.

Thank you for clarifications.
Does it mean that I can state in PV protocols that XEN_E??? error codes are
used and still use Linux error codes directly in Linux front/back w/o
complains
from the community because of no conversion? :)

I guess if it's inside of the Linux kernel that's fine (although that's a
question for the Linux maintainers). If it runs in user-space you certainly
need to use the XEN_E error codes.

clear

Roger.

Thank you

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

Re: [Xen-devel] [PATCH v1] displif: add ABI for para-virtual display

2017-01-26 Thread Oleksandr Andrushchenko 

Hi, Jan!

Does the below answer your question?

Thank you,
Oleksandr

On 01/05/2017 08:07 PM, Oleksandr Andrushchenko wrote:

On 01/05/2017 06:12 PM, Jan Beulich wrote:

On 05.01.17 at 17:03,  wrote:

On 01/05/2017 05:45 PM, Jan Beulich wrote:

On 22.12.16 at 09:12,  wrote:

Other than that the primary thing I'm missing (as I think I've
mentioned elsewhere already) is a rationale of why this new
protocol is needed (and the existing xenfb one can't be extended).

"This protocol aims to provide a unified protocol which fits more

sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
   o multiple dynamically allocated/destroyed framebuffers
   o buffers of arbitrary sizes
   o better configuration options including multiple display support"

Well, that's all stuff you had spelled out in the accompanying mail,
but that's all items which could be taken care of by a protocol
extension too.

of course

I tried to evaluate what would it be like to extend existing fbif...
It looks like having 2 different protocols in a single file.

This is what I'd like you to expand on.

To start with:

1. In/out event sizes
 o fbif - 40 octets
 o displif - 40 octets
It fits now, but this is only the initial version of the displif protocol
which means that there could be requests which will not fit
(we are thinking of introducing some GPU related functionality
later on). In that case we cannot alter fbif sizes as we need to
be backward compatible an will be forced to handle those
apart of fbif. This makes me believe if we extend fbif it is better
to have separate structures/rings from the start.

2. Shared page
Displif doesn't use anything like struct xenfb_page, but
DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct 
xendispl_resp);

which I believe is a better and more common way.
Output events use a shared page which only has in_cons and in_prod
and all the rest is used for incoming events. Here struct xenfb_page
could probably be used as is despite the fact that it only has a half
of a page for incoming events which is only 50 events. (consider
something like 60Hz display)

3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif
than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.
BTW, I can add framebuffer's update and resize into displif, so
it could  probably supersede fbif at some point


What is more fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM

And this is certainly a valid argument (which hence should be
spelled out in the description).

ok

Jan






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

Re: [Xen-devel] POSIX error names and codes in PV protocols

2017-01-26 Thread Roger Pau Monné 
On Thu, Jan 26, 2017 at 08:14:10PM +0200, Oleksandr Andrushchenko wrote:
> On 01/26/2017 07:38 PM, Roger Pau Monné wrote:
> > On Thu, Jan 26, 2017 at 07:28:44PM +0200, Oleksandr Andrushchenko wrote:
> > > On 01/26/2017 05:44 PM, Jan Beulich wrote:
> > > > > > > On 26.01.17 at 15:40,  wrote:
> > > > > There is some work happening on new PV protocols: sndif [1],
> > > > > 
> > > > > displif [2], PV calls [3] and the common part of those is that
> > > > > 
> > > > > error/status codes must be returned as a part of a response packet.
> > > > > 
> > > > > For that Konrad suggested [1] (and Stefano already used in [3]) POSIX
> > > > > 
> > > > > to be employed here instead of defining protocol specific error codes.
> > > > > 
> > > > > The problem I see here is that POSIX only defines names of the errors,
> > > > > 
> > > > > but not values [4]. So, in order to use POSIX one still needs to 
> > > > > define
> > > > > 
> > > > > the values (names must be the same, but values may differ for 
> > > > > different
> > > > > OSes).
> > > > > 
> > > > > So, the question is what would be the best option to
> > > > > 
> > > > > a) have those numbers defined in OS agnostic way
> > > > > 
> > > > > b) have those defined for all PV protocols
> > > > > 
> > > > > Stefano has already defined the error code values in his work [3],
> > > > > 
> > > > > but for other protocols this should be reimplemented again.
> > > > Aren't these simply what public/errno.h provides? Why would any
> > > > Xen specific protocol want to define their own, now that we have
> > > > this base set?
> > > > 
> > > > Jan
> > > Indeed, thank you
> > > The problem is that it is not exposed to Linux, but I can see it
> > > in FreeBSD [1] and the helper to convert error codes [2] there as well.
> > > Is there any reason these are not available in Linux?
> > Xen error codes are Linux error codes, so I guess there's basically no need 
> > to
> > use them on Linux (although it would be good, just so that people is aware 
> > that
> > Xen and Linux are in different theoretical spaces, which happen to match in
> > Linux's case).
> > 
> > Roger.
> Thank you for clarifications.
> Does it mean that I can state in PV protocols that XEN_E??? error codes are
> used and still use Linux error codes directly in Linux front/back w/o
> complains
> from the community because of no conversion? :)

I guess if it's inside of the Linux kernel that's fine (although that's a
question for the Linux maintainers). If it runs in user-space you certainly
need to use the XEN_E error codes.

Roger.

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

Re: [Xen-devel] POSIX error names and codes in PV protocols

2017-01-26 Thread Oleksandr Andrushchenko 

On 01/26/2017 07:38 PM, Roger Pau Monné wrote:

On Thu, Jan 26, 2017 at 07:28:44PM +0200, Oleksandr Andrushchenko wrote:

On 01/26/2017 05:44 PM, Jan Beulich wrote:

On 26.01.17 at 15:40,  wrote:

There is some work happening on new PV protocols: sndif [1],

displif [2], PV calls [3] and the common part of those is that

error/status codes must be returned as a part of a response packet.

For that Konrad suggested [1] (and Stefano already used in [3]) POSIX

to be employed here instead of defining protocol specific error codes.

The problem I see here is that POSIX only defines names of the errors,

but not values [4]. So, in order to use POSIX one still needs to define

the values (names must be the same, but values may differ for different
OSes).

So, the question is what would be the best option to

a) have those numbers defined in OS agnostic way

b) have those defined for all PV protocols

Stefano has already defined the error code values in his work [3],

but for other protocols this should be reimplemented again.

Aren't these simply what public/errno.h provides? Why would any
Xen specific protocol want to define their own, now that we have
this base set?

Jan

Indeed, thank you
The problem is that it is not exposed to Linux, but I can see it
in FreeBSD [1] and the helper to convert error codes [2] there as well.
Is there any reason these are not available in Linux?

Xen error codes are Linux error codes, so I guess there's basically no need to
use them on Linux (although it would be good, just so that people is aware that
Xen and Linux are in different theoretical spaces, which happen to match in
Linux's case).

Roger.

Thank you for clarifications.
Does it mean that I can state in PV protocols that XEN_E??? error codes are
used and still use Linux error codes directly in Linux front/back w/o 
complains

from the community because of no conversion? :)


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

[Xen-devel] [PATCH] x86/xen: Fix APIC id mismatch warning on Intel

2017-01-26 Thread Mohit Gambhir 

This patch fixes the following warning message seen when booting the
kernel as Dom0 with Xen on Intel machines.

[0.003000] [Firmware Bug]: CPU1: APIC id mismatch. Firmware: 0 APIC: 1]

The code generating the warning in validate_apic_and_package_id() matches
cpu_data(cpu).apicid (initialized in init_intel()->
detect_extended_topology() using cpuid) against the apicid returned from
xen_apic_read(). Now, xen_apic_read() makes a hypercall to retrieve apicid
for the boot  cpu but returns 0 otherwise. Hence the warning gets thrown
for all but the boot cpu.

The idea behind xen_apic_read() returning 0 for apicid is that the
guests (even Dom0) should not need to know what physical processor their
vcpus are running on. This is because we currently  do not have topology
information in Xen and also because xen allows more vcpus than physical
processors. However, boot cpu's apicid is required for loading
xen-acpi-processor driver on AMD machines. Look at following patch for
details:

commit 558daa289a40 ("xen/apic: Return the APIC ID (and version) for CPU
0.")

So to get rid of the warning, this patch modifies
xen_cpu_present_to_apicid() to return cpu_data(cpu).apicid instead of
calling xen_apic_read().

The warning is not seen on AMD machines because init_amd() populates
cpu_data(cpu).apicid by calling hard_smp_processor_id()->xen_apic_read()
as opposed to using apicid from cpuid as is done on Intel machines.

Signed-off-by: Mohit Gambhir 
---
 arch/x86/xen/apic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/apic.c b/arch/x86/xen/apic.c
index 44c88ad..bcea81f 100644
--- a/arch/x86/xen/apic.c
+++ b/arch/x86/xen/apic.c
@@ -145,7 +145,7 @@ static void xen_silent_inquire(int apicid)
 static int xen_cpu_present_to_apicid(int cpu)
 {
 if (cpu_present(cpu))
-return xen_get_apic_id(xen_apic_read(APIC_ID));
+return cpu_data(cpu).apicid;
 else
 return BAD_APICID;
 }
--
2.9.3


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

Re: [Xen-devel] [PATCH] flask: fix build after the introduction of DMOP

2017-01-26 Thread Daniel De Graaf 

On 01/25/2017 05:43 AM, Wei Liu wrote:

In 58cbc034 send_irq permission was removed but there was still
reference to it in policy file. Remove the stale reference.

And now we also need dm permission. Add that.

Signed-off-by: Wei Liu 


Acked-by: Daniel De Graaf 


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

Re: [Xen-devel] [PATCH] [incremental] xsm/build: Further build fixes following the DMop series

2017-01-26 Thread Daniel De Graaf 

On 01/25/2017 09:24 AM, Andrew Cooper wrote:

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Daniel De Graaf 
CC: Paul Durrant 
CC: Ian Jackson 

Might be better to merge into one single patch when committed?


Either way (combined with prior patch, original series, or alone):

Acked-by: Daniel De Graaf 


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

Re: [Xen-devel] [PATCH] arm/monitor: flush the icache during SMC traps

2017-01-26 Thread Tamas K Lengyel 
On Thu, Jan 26, 2017 at 4:30 AM, Julien Grall  wrote:
> (CC xen-devel, Ravzan, and Stefao)
>
> Hi Tamas,
>
> Not sure why you only CC me on the answer. I have CCed again xen-devel as I
> don't see any sensible discussion in it.
>
> On 26/01/2017 00:11, Tamas K Lengyel wrote:
>>
>> On Wed, Jan 25, 2017 at 3:41 PM, Julien Grall 
>> wrote:
>>>
>>> Hi Tamas,
>>>
>>> On 25/01/2017 20:02, Tamas K Lengyel wrote:


 During an SMC trap it is possible that the user may change the memory
>>>
>>>
>>>
>>> By user, do you mean the monitor application?
>>
>>
>> Yes.
>
>
> It would be worth clarifying in the commit message.
>
>
>>
>>>
 from where the SMC was fetched. However, without flushing the icache
 the SMC may still trigger if the pCPU was idle during the trap. Flush
 the icache to ensure consistency.
>>>
>>>
>>>
>>> invalidate_icache will invalidate the cache to PoU on all the pCPUs. But
>>> here you only mention a problem on the current pCPU. So which behavior do
>>> you want to achieve?
>>
>>
>> It would be sufficient to flush the icache on the specific pCPU that
>> trapped with the SMC. Didn't see anything defined in Xen to achieve
>> that.
>>
>>>

 Signed-off-by: Tamas K Lengyel 
 ---
 Cc: Razvan Cojocaru 
 Cc: Stefano Stabellini 
 Cc: Julien Grall 
 ---
  xen/arch/arm/monitor.c | 3 +++
  1 file changed, 3 insertions(+)

 diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c
 index 59ce8f635f..ae1b97993f 100644
 --- a/xen/arch/arm/monitor.c
 +++ b/xen/arch/arm/monitor.c
 @@ -63,6 +63,9 @@ int monitor_smc(void)
  .reason = VM_EVENT_REASON_PRIVILEGED_CALL
  };

 +/* Nuke the icache as the memory may get changed underneath us. */
 +invalidate_icache();
 +
>>>
>>>
>>>
>>> Can you explain why you put this call before the monitor trap and not
>>> after?
>>> From my understanding the monitoring application may change the memory.
>>> But
>>> by the time you modify the instruction, the instruction cache may have
>>> prefetched the previous instruction. So the problem is still there.
>>
>>
>> Not sure how would that happen exactly? The vCPU gets paused until the
>> user responds to the vm_event request, so where would it perform the
>> prefetch again? Also, with this change I've verified that the repeated
>> SMC issue no longer presents itself (it has been triggered quite
>> regularly on the hikey before).
>
>
> The ARM ARM provides a set of expected behavior and where to call the cache
> maintenance instruction. If it is not done correctly, it may not affect your
> platform but at some point in the future (or even already today) it will
> break a platform. I wish you good luck to debug that when it happens. It is
> a really nightmare :).
>
> So what I care the most is what is the correct behavior based on the ARM
> ARM. A good overview can be found in a talk made by Mark Rutland [1].
>
> What I was concerned about is the instruction cache been shared between
> multiple processors (for instance L2 cache or higher). A vCPU could also get
> rescheduled to another processor afterwards. Leading to accessing an out of
> date instruction cache.

 I see, yea, in that case the instruction may still trigger regardless. Sigh.

>
>>
>> Also, for multi-vCPU guest another vCPU fetching the SMC before the
>> memory modification happen (ie. just after this flush) is not a
>> problem and is expected behavior. Providing a non-racy setup for
>> trapping on multi-vCPU guests requires other work (like altp2m).
>
>
> I am not that concerned about the SMC itself, but the fact that you may
> modify the guest memory whilst it is running. So another vCPU may end up to
> execute a mix between new and old instructions depending of the state of its
> instruction cache. That would result to a potential undefined behavior.
>
> Also, you want to make sure that if you write another SMC in memory, it is
> effectively affecting all the vCPUs now and not a moment after.

Yeap.

>
> So I still think the invalidate_icache should be done afterwards. IHMO
> modifying guest instructions while other vCPU are running is very fragile as
> other thread may execute the instructions your are running.

I see your point, just got confused because the return from
monitor_traps is not the return from the user. That just sends off the
notification to the user. The actual return happens elsewhere once the
user replies. That would be the point where the flush should happen.

>
>>
>>>
>>> Furthermore, the instruction cache may not snoop the data cache. So you
>>> have
>>> to ensure the data written reached the memory. Otherwise you may read the
>>> previous instruction. Where is it done? If you expect the monitor app to
>>> flush the data cache, then please comment it.
>>
>>
>> AFAICT there is no

Re: [Xen-devel] POSIX error names and codes in PV protocols

2017-01-26 Thread Roger Pau Monné 
On Thu, Jan 26, 2017 at 07:28:44PM +0200, Oleksandr Andrushchenko wrote:
> On 01/26/2017 05:44 PM, Jan Beulich wrote:
> > > > > On 26.01.17 at 15:40,  wrote:
> > > There is some work happening on new PV protocols: sndif [1],
> > > 
> > > displif [2], PV calls [3] and the common part of those is that
> > > 
> > > error/status codes must be returned as a part of a response packet.
> > > 
> > > For that Konrad suggested [1] (and Stefano already used in [3]) POSIX
> > > 
> > > to be employed here instead of defining protocol specific error codes.
> > > 
> > > The problem I see here is that POSIX only defines names of the errors,
> > > 
> > > but not values [4]. So, in order to use POSIX one still needs to define
> > > 
> > > the values (names must be the same, but values may differ for different
> > > OSes).
> > > 
> > > So, the question is what would be the best option to
> > > 
> > > a) have those numbers defined in OS agnostic way
> > > 
> > > b) have those defined for all PV protocols
> > > 
> > > Stefano has already defined the error code values in his work [3],
> > > 
> > > but for other protocols this should be reimplemented again.
> > Aren't these simply what public/errno.h provides? Why would any
> > Xen specific protocol want to define their own, now that we have
> > this base set?
> > 
> > Jan
> Indeed, thank you
> The problem is that it is not exposed to Linux, but I can see it
> in FreeBSD [1] and the helper to convert error codes [2] there as well.
> Is there any reason these are not available in Linux?

Xen error codes are Linux error codes, so I guess there's basically no need to
use them on Linux (although it would be good, just so that people is aware that
Xen and Linux are in different theoretical spaces, which happen to match in
Linux's case).

Roger.

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

Re: [Xen-devel] POSIX error names and codes in PV protocols

2017-01-26 Thread Julien Grall 

Hi,

On 26/01/2017 17:28, Oleksandr Andrushchenko wrote:

On 01/26/2017 05:44 PM, Jan Beulich wrote:

On 26.01.17 at 15:40,  wrote:

There is some work happening on new PV protocols: sndif [1],

displif [2], PV calls [3] and the common part of those is that

error/status codes must be returned as a part of a response packet.

For that Konrad suggested [1] (and Stefano already used in [3]) POSIX

to be employed here instead of defining protocol specific error codes.

The problem I see here is that POSIX only defines names of the errors,

but not values [4]. So, in order to use POSIX one still needs to define

the values (names must be the same, but values may differ for different
OSes).

So, the question is what would be the best option to

a) have those numbers defined in OS agnostic way

b) have those defined for all PV protocols

Stefano has already defined the error code values in his work [3],

but for other protocols this should be reimplemented again.

Aren't these simply what public/errno.h provides? Why would any
Xen specific protocol want to define their own, now that we have
this base set?

Jan

Indeed, thank you
The problem is that it is not exposed to Linux, but I can see it
in FreeBSD [1] and the helper to convert error codes [2] there as well.
Is there any reason these are not available in Linux?


This is because Linux and Xen are using the exact same error codes. The 
one in FreeBSD differs a bit, hence the helper to convert errors.


Strictly speaking Linux should have a converter, but it is not necessary 
today.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] POSIX error names and codes in PV protocols

2017-01-26 Thread Oleksandr Andrushchenko 

On 01/26/2017 05:44 PM, Jan Beulich wrote:

On 26.01.17 at 15:40,  wrote:

There is some work happening on new PV protocols: sndif [1],

displif [2], PV calls [3] and the common part of those is that

error/status codes must be returned as a part of a response packet.

For that Konrad suggested [1] (and Stefano already used in [3]) POSIX

to be employed here instead of defining protocol specific error codes.

The problem I see here is that POSIX only defines names of the errors,

but not values [4]. So, in order to use POSIX one still needs to define

the values (names must be the same, but values may differ for different
OSes).

So, the question is what would be the best option to

a) have those numbers defined in OS agnostic way

b) have those defined for all PV protocols

Stefano has already defined the error code values in his work [3],

but for other protocols this should be reimplemented again.

Aren't these simply what public/errno.h provides? Why would any
Xen specific protocol want to define their own, now that we have
this base set?

Jan

Indeed, thank you
The problem is that it is not exposed to Linux, but I can see it
in FreeBSD [1] and the helper to convert error codes [2] there as well.
Is there any reason these are not available in Linux?

Besides this fact,
Konrad, Stefano, are you ok that we say in the protocol file that
these are the error codes used?
As error codes are unsigned ints, what should be used in packets?
uint16_t or uint32_t?

Thank you,
Oleksandr

[1] https://github.com/freebsd/freebsd/blob/master/sys/xen/interface/errno.h
[2] https://github.com/freebsd/freebsd/blob/master/sys/xen/error.h


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

Re: [Xen-devel] [PATCH v1 1/3] x86/pvclock: add setter for pvclock_pvti_cpu0_va

2017-01-26 Thread Andy Lutomirski 
On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins  wrote:
> Right now there is only a pvclock_pvti_cpu0_va() which is defined
> on kvmclock since:
>
> commit dac16fba6fc5
> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
>
> The only user of this interface was kvm. This commit moves
> pvclock_pvti_cpu0_va to pvclock which is a more generic place to have it
> and adds the correspondent setter routine for it. This allows other
> pvclock-based clocksources to use it, such as Xen.

With a minor nit:

Acked-by: Andy Lutomirski 

> +#else
> +static inline void pvclock_set_pvti_cpu0_va(struct 
> pvclock_vsyscall_time_info *pvti)
> +{
> +}

How about just not providing pvclock_set_pvti_cpu0_va() in this case?
It'll save three lines of code, and, more importantly, it will force
us to notice if we screw up the Kconfig stuff.

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

Re: [Xen-devel] [PATCH v1 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

2017-01-26 Thread Andy Lutomirski 
On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins  wrote:
> This file defines an ABI shared between guest and hypervisor(s)
> (KVM, Xen) and as such there should be an correspondent entry in
> MAINTAINERS file. Notice that there's already a text notice at the
> top of the header file, hence this commit simply enforces it more
> explicitly and have both peers noticed when such changes happen.
>
> Signed-off-by: Joao Martins 
> ---
> This was suggested by folks at xen-devel as we missed some of the
> ABI additions (e.g. flags field in pvti, TSC stable bit) - so this
> patch is to help preventing that from happening. Alternatively I
> could instead add a "PVCLOCK ABI" section in this file with the
> two mailing lists.

If you do the latter, please add me as an R:.

--Andy

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

Re: [Xen-devel] [PATCH] flask: fix build after the introduction of DMOP

2017-01-26 Thread Wei Liu 
On Thu, Jan 26, 2017 at 10:22:52AM +, Wei Liu wrote:
> On Wed, Jan 25, 2017 at 10:43:11AM +, Wei Liu wrote:
> > In 58cbc034 send_irq permission was removed but there was still
> > reference to it in policy file. Remove the stale reference.
> > 
> > And now we also need dm permission. Add that.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Daniel De Graaf 
> 
> FAOD: Daniel I will need you ack before I can apply these two patches.

Actually I'm going to commit these patches now because staging is
blocked, so this is a bit urgent.

Daniel, please review them all the same and tell us if you think things
should be done differently. I will then post incremental patch for that.

Wei.

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

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

2017-01-26 Thread Ian Jackson 
Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104684: regressions 
- FAIL"):
> On 01/26/2017 08:23 AM, osstest service owner wrote:
> > flight 104684 linux-linus real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/104684/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
...
> I don't see why ARM tests fail. But then I also don't see (in the serial
> log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
> but there it nothing coming to the console from it.

Yes.

Unfortunately the osstest bisector is having some trouble with this
because the basis revision combination includes Xen f3a7ca02400d which
is ancient and doesn't build now on armhf, although it built before.
(I think the difference is that the compiler has been updated by
Debian.)

Since there is no output from Xen, I think this must be a problem with
the Xen image, not anything to do with Linux.

The history for this test is here:
  
http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus

In xen-unstable, there is what looks like a different failure:
  
http://logs.test-lab.xenproject.org/osstest/logs/104681/test-armhf-armhf-xl/serial-arndale-westfield.log

The machine in 104684 is cubietruck-metzinger which seems fine:
  
http://logs.test-lab.xenproject.org/osstest/results/host/cubietruck-metzinger.html

Here are the histories on the linux-linus and xen-unstable branches:
  
http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/linux-linus
  
http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable

I think there may be a host-specific bug in ARM in xen-unstable ?

> There is output from 3.16 kernels though.

I think the 3.16 tests you are refrring to are running with a
different version of Xen and on different hardware.

Ian.

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

Re: [Xen-devel] [PATCH v1 2/3] x86/xen/time: setup vcpu 0 time info page

2017-01-26 Thread Andy Lutomirski 
On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins  wrote:
> In order to support pvclock vdso on xen we need to setup the time
> info page for vcpu 0 and register the page with Xen using the
> VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
> will also forcefully update the pvti which will set some of the
> necessary flags for vdso. Afterwards we check if it supports the
> PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
> vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
> will be later on used when mapping the vdso image.
>
> The xen headers are also updated to include the new hypercall for
> registering the secondary vcpu_time_info struct.

No objections from me assuming the code is correct.

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

[Xen-devel] [xen-unstable-smoke test] 104722: regressions - trouble: blocked/broken/fail

2017-01-26 Thread osstest service owner 
flight 104722 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104722/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-buildfail REGR. vs. 104630
 build-armhf   5 xen-buildfail REGR. vs. 104630

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  4fda891f99c47bc08fe023a22177cba4b02234b4
baseline version:
 xen  c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc

Last test of basis   104630  2017-01-24 19:01:56 Z1 days
Failing since104642  2017-01-25 10:01:54 Z1 days   29 attempts
Testing same since   104722  2017-01-26 17:00:56 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Dario Faggioli 
  Elena Ufimtseva 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Paul Lai 
  Praveen Kumar 
  Roger Pau Monné 
  Tim Deegan 
  Venu Busireddy 
  Wei Liu 

jobs:
 build-amd64  fail
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt 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.

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

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

Re: [Xen-devel] Xen 4.9 Development Update

2017-01-26 Thread Wei Liu 
On Thu, Jan 26, 2017 at 12:27:15PM +, Julien Grall wrote:
> Hi,
> 
> On 09/12/2016 19:09, Andrew Cooper wrote:
> > On 09/12/16 19:01, Stefano Stabellini wrote:
> > > On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
> > > > On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
> > > > > On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko 
> > > > > wrote:
> > > > > > > > Should we have a section on new PV drivers? If so, I suggest to 
> > > > > > > > add:
> > > > > > > > - Xen transport for 9pfs
> > > > > > > > - PV Calls
> > > > > > > Good idea. We could also include DRM and PV Sound (CC Oleksandr).
> > > > > > > 
> > > > > > This is a great idea. Let me explain what we have and what the 
> > > > > > direction
> > > > > > is:
> > > > > > 1. Frontends which we already have, working, but need to 
> > > > > > refactor/cleanup:
> > > > > > 1.1. PV sound
> > > > > > 1.2. PV DRM
> > > > > > 1.3. DISPL protocol, I will push v1 for review right after sndif 
> > > > > > done
> > > > > > 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero 
> > > > > > copy
> > > > > > via DRM Prime buffer sharing)
> > > > > > 1.4. PV events not done, but we are considering [1]. If it fits and
> > > > > > is maintained,
> > > > > > then we'll probably stick to it, otherwise new PV will be created
> > > > > > 
> > > > > > 2. Backends, for the above frontends already implemented:
> > > > > > 2.1. A unified library for Xen backends (libxenbe)
> > > > > > 2.2. DRM + Wayland
> > > > > > 2.3. ALSA
> > > > > > 2.4. Events not implemented yet
> > > > > > 
> > > > > > All the above sources are available on *public* Github repos
> > > > > > (I can provide links on request) and the intention is to
> > > > > > upstream.
> > > > > > 
> > > > > Please do post the links..
> > > > Please note these are all WIP:
> > > > 1. Frontends
> > > > https://github.com/andr2000?tab=repositories
> > > > 2. Backends
> > > > https://github.com/al1img?tab=repositories
> > > Now, I don't want to sound pessimistic, but I thought I was being
> > > audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
> > > think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
> > > PV DRM frontends and backends, all by April? I would probably reduce the
> > > list a bit.
> > 
> > I think it would be good to main two lists.  One of "the stuff people
> > are working on overall", and "the subset of it intended/expected for the
> > forthcoming release".
> > 
> > Stuff will invariably slip, but even if the work isn't intended for the
> > forthcoming release, it it still useful to see if anyone in the
> > community is working on a related topic.
> 
> I am thinking to re-introduce the state of a series (none, fair, ok, good,
> done) as it was done in the past [1].
> 
> "The states are: none -> fair -> ok -> good -> done
> 
> none - nothing yet
> fair - still working on it, patches are prototypes or RFC
> ok   - patches posted, acting on review
> good - some last minute pieces
> done - all done, might have bugs"
> 

We (I?) ditched them because they weren't that useful.  "None" is just
signalling of intent, which doesn't carry enough of meaningful
information.  "Fair", "ok" and "good" are all subjective -- we've seen
"good" series slipped due to last minute issues.

If we really want status, I would suggest more concrete status:

  design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed

These are more tangible and objective.

> Also, rather than having two separate lists as you suggested, I would
> combine the two and differentiate the items planned for next release with a
> tag (let's say [next]).
> 

No opinion on this.

Wei.

> Any opinions?
> 
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg01816.html
> 
> -- 
> Julien Grall

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

[Xen-devel] [PATCH v2 2/3] x86: Remap GDT tables in the Fixmap section

2017-01-26 Thread Thomas Garnier 
Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section (PAGE_OFFSET).

This patch relocates the GDT table for each processor inside the
Fixmap section. The space is reserved based on number of supported
processors.

For consistency, the remapping is done by default on 32 and 64 bit.

Each processor switches to its remapped GDT at the end of
initialization. For hibernation, the main processor returns with the
original GDT and switches back to the remapping at completion.

This patch was tested on both architectures. Hibernation and KVM were
both tested specially for their usage of the GDT.

Signed-off-by: Thomas Garnier 
---
Based on next-20170125
---
 arch/x86/entry/vdso/vma.c |  2 +-
 arch/x86/include/asm/desc.h   | 23 +++
 arch/x86/include/asm/fixmap.h |  4 
 arch/x86/include/asm/processor.h  |  1 +
 arch/x86/include/asm/stackprotector.h |  2 +-
 arch/x86/kernel/acpi/sleep.c  |  2 +-
 arch/x86/kernel/apm_32.c  |  6 +++---
 arch/x86/kernel/cpu/common.c  | 26 --
 arch/x86/kernel/setup_percpu.c|  2 +-
 arch/x86/kernel/smpboot.c |  2 +-
 arch/x86/platform/efi/efi_32.c|  4 ++--
 arch/x86/power/cpu.c  |  7 +--
 arch/x86/xen/enlighten.c  |  2 +-
 arch/x86/xen/smp.c|  2 +-
 drivers/lguest/x86/core.c |  6 +++---
 drivers/pnp/pnpbios/bioscalls.c   | 10 +-
 16 files changed, 73 insertions(+), 28 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 10820f6cefbf..acae4ef04cdf 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -353,7 +353,7 @@ static void vgetcpu_cpu_init(void *arg)
d.p = 1;/* Present */
d.d = 1;/* 32-bit */
 
-   write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, , 
DESCTYPE_S);
+   write_gdt_entry(get_cpu_direct_gdt(cpu), GDT_ENTRY_PER_CPU, , 
DESCTYPE_S);
 }
 
 static int vgetcpu_online(unsigned int cpu)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 12080d87da3b..4cc176f57b78 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -45,11 +46,25 @@ struct gdt_page {
 
 DECLARE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page);
 
-static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu)
+/* Provide the original GDT */
+static inline struct desc_struct *get_cpu_direct_gdt(unsigned int cpu)
 {
return per_cpu(gdt_page, cpu).gdt;
 }
 
+/* Get the fixmap index for a specific processor */
+static inline unsigned int get_cpu_fixmap_gdt_index(int cpu)
+{
+   return FIX_GDT_REMAP_BEGIN + cpu;
+}
+
+/* Provide the fixmap address of the remapped GDT */
+static inline struct desc_struct *get_cpu_fixmap_gdt(int cpu)
+{
+   unsigned int idx = get_cpu_fixmap_gdt_index(cpu);
+   return (struct desc_struct *)__fix_to_virt(idx);
+}
+
 #ifdef CONFIG_X86_64
 
 static inline void pack_gate(gate_desc *gate, unsigned type, unsigned long 
func,
@@ -174,7 +189,7 @@ static inline void set_tssldt_descriptor(void *d, unsigned 
long addr, unsigned t
 
 static inline void __set_tss_desc(unsigned cpu, unsigned int entry, void *addr)
 {
-   struct desc_struct *d = get_cpu_gdt_table(cpu);
+   struct desc_struct *d = get_cpu_direct_gdt(cpu);
tss_desc tss;
 
/*
@@ -202,7 +217,7 @@ static inline void native_set_ldt(const void *addr, 
unsigned int entries)
 
set_tssldt_descriptor(, (unsigned long)addr, DESC_LDT,
  entries * LDT_ENTRY_SIZE - 1);
-   write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_LDT,
+   write_gdt_entry(get_cpu_direct_gdt(cpu), GDT_ENTRY_LDT,
, DESC_LDT);
asm volatile("lldt %w0"::"q" (GDT_ENTRY_LDT*8));
}
@@ -244,7 +259,7 @@ static inline unsigned long native_store_tr(void)
 
 static inline void native_load_tls(struct thread_struct *t, unsigned int cpu)
 {
-   struct desc_struct *gdt = get_cpu_gdt_table(cpu);
+   struct desc_struct *gdt = get_cpu_direct_gdt(cpu);
unsigned int i;
 
for (i = 0; i < GDT_ENTRY_TLS_ENTRIES; i++)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index c46289799b02..8b913b5e9383 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -100,6 +100,10 @@ enum fixed_addresses {
 #ifdef CONFIG_X86_INTEL_MID
FIX_LNW_VRTC,
 #endif
+   /* Fixmap entries to remap the GDTs, one per processor. */
+

[Xen-devel] [PATCH v2 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

2017-01-26 Thread Thomas Garnier 
This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.

It will allow GDT remapping in the Fixmap section. The current
MODULES_END static address does not provide enough space for the kernel
to support a large number of processors.

Signed-off-by: Thomas Garnier 
---
Based on next-20170125
---
 arch/x86/include/asm/fixmap.h   | 8 
 arch/x86/include/asm/pgtable_64_types.h | 3 ---
 arch/x86/kernel/module.c| 1 +
 arch/x86/mm/dump_pagetables.c   | 1 +
 arch/x86/mm/kasan_init_64.c | 1 +
 5 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 8554f960e21b..c46289799b02 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -132,6 +132,14 @@ enum fixed_addresses {
 
 extern void reserve_top_address(unsigned long reserve);
 
+/* On 64bit, the module sections ends with the start of the fixmap */
+#ifdef CONFIG_X86_64
+#define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
+#define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
+#define MODULES_LEN   (MODULES_END - MODULES_VADDR)
+#endif /* CONFIG_X86_64 */
+
+
 #define FIXADDR_SIZE   (__end_of_permanent_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START  (FIXADDR_TOP - FIXADDR_SIZE)
 
diff --git a/arch/x86/include/asm/pgtable_64_types.h 
b/arch/x86/include/asm/pgtable_64_types.h
index 3a264200c62f..de8bace10200 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -66,9 +66,6 @@ typedef struct { pteval_t pte; } pte_t;
 #define VMEMMAP_START  __VMEMMAP_BASE
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 #define VMALLOC_END(VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
-#define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
-#define MODULES_END  _AC(0xff00, UL)
-#define MODULES_LEN   (MODULES_END - MODULES_VADDR)
 #define ESPFIX_PGD_ENTRY _AC(-2, UL)
 #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
 #define EFI_VA_START( -4 * (_AC(1, UL) << 30))
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 477ae806c2fa..fad61caac75e 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if 0
 #define DEBUGP(fmt, ...)   \
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index ea9c49adaa1f..eefd6d015d02 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -18,6 +18,7 @@
 #include 
 
 #include 
+#include 
 
 /*
  * The dumper groups pagetable entries of the same type into one, and for
diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
index 0493c17b8a51..34f167cf3316 100644
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 
 extern pgd_t early_level4_pgt[PTRS_PER_PGD];
 extern struct range pfn_mapped[E820_X_MAX];
-- 
2.11.0.483.g087da7b7c-goog


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

[Xen-devel] [PATCH v2 3/3] x86: Make the GDT remapping read-only on 64 bit

2017-01-26 Thread Thomas Garnier 
This patch makes the GDT remapped pages read-only to prevent corruption.
This change is done only on 64 bit.

The native_load_tr_desc function was adapted to correctly handle a
read-only GDT. The LTR instruction always writes to the GDT TSS entry.
This generates a page fault if the GDT is read-only. This change checks
if the current GDT is a remap and swap GDTs as needed. This function was
tested by booting multiple machines and checking hibernation works
properly.

KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the
per-cpu variable was removed for functions to fetch the original GDT.
Instead of reloading the previous GDT, VMX will reload the fixmap GDT as
expected. For testing, VMs were started and restored on multiple
configurations.

Signed-off-by: Thomas Garnier 
---
Based on next-20170125
---
 arch/x86/include/asm/desc.h  | 46 +++-
 arch/x86/include/asm/processor.h |  1 +
 arch/x86/kernel/cpu/common.c | 28 ++--
 arch/x86/kvm/svm.c   |  4 +---
 arch/x86/kvm/vmx.c   | 15 +
 5 files changed, 70 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 4cc176f57b78..ca7b2224fcb4 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -52,6 +52,12 @@ static inline struct desc_struct 
*get_cpu_direct_gdt(unsigned int cpu)
return per_cpu(gdt_page, cpu).gdt;
 }
 
+/* Provide the current original GDT */
+static inline struct desc_struct *get_current_direct_gdt(void)
+{
+   return this_cpu_ptr(_page)->gdt;
+}
+
 /* Get the fixmap index for a specific processor */
 static inline unsigned int get_cpu_fixmap_gdt_index(int cpu)
 {
@@ -223,11 +229,6 @@ static inline void native_set_ldt(const void *addr, 
unsigned int entries)
}
 }
 
-static inline void native_load_tr_desc(void)
-{
-   asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
-}
-
 static inline void native_load_gdt(const struct desc_ptr *dtr)
 {
asm volatile("lgdt %0"::"m" (*dtr));
@@ -248,6 +249,41 @@ static inline void native_store_idt(struct desc_ptr *dtr)
asm volatile("sidt %0":"=m" (*dtr));
 }
 
+/*
+ * The LTR instruction marks the TSS GDT entry as busy. In 64bit, the GDT is
+ * a read-only remapping. To prevent a page fault, the GDT is switched to the
+ * original writeable version when needed.
+ */
+#ifdef CONFIG_X86_64
+static inline void native_load_tr_desc(void)
+{
+   struct desc_ptr gdt;
+   int cpu = raw_smp_processor_id();
+   bool restore = false;
+   struct desc_struct *fixmap_gdt;
+
+   native_store_gdt();
+   fixmap_gdt = get_cpu_fixmap_gdt(cpu);
+
+   /*
+* If the current GDT is the read-only fixmap, swap to the original
+* writeable version. Swap back at the end.
+*/
+   if (gdt.address == (unsigned long)fixmap_gdt) {
+   load_direct_gdt(cpu);
+   restore = true;
+   }
+   asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
+   if (restore)
+   load_fixmap_gdt(cpu);
+}
+#else
+static inline void native_load_tr_desc(void)
+{
+   asm volatile("ltr %w0"::"q" (GDT_ENTRY_TSS*8));
+}
+#endif
+
 static inline unsigned long native_store_tr(void)
 {
unsigned long tr;
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 22801fd345dc..e8e68b00a2ec 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -705,6 +705,7 @@ extern struct desc_ptr  early_gdt_descr;
 
 extern void cpu_set_gdt(int);
 extern void switch_to_new_gdt(int);
+extern void load_direct_gdt(int);
 extern void load_fixmap_gdt(int);
 extern void load_percpu_segment(int);
 extern void cpu_init(void);
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 15f06cf3e3d4..a7a54f57b68a 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -444,13 +444,31 @@ void load_percpu_segment(int cpu)
load_stack_canary_segment();
 }
 
+/* On 64bit the GDT remapping is read-only */
+#ifdef CONFIG_X86_64
+#define PAGE_FIXMAP_GDT PAGE_KERNEL_RO
+#else
+#define PAGE_FIXMAP_GDT PAGE_KERNEL
+#endif
+
 /* Setup the fixmap mapping only once per-processor */
 static inline void setup_fixmap_gdt(int cpu)
 {
__set_fixmap(get_cpu_fixmap_gdt_index(cpu),
-__pa(get_cpu_direct_gdt(cpu)), PAGE_KERNEL);
+__pa(get_cpu_direct_gdt(cpu)), PAGE_FIXMAP_GDT);
 }
 
+/* Load the original GDT from the per-cpu structure */
+void load_direct_gdt(int cpu)
+{
+   struct desc_ptr gdt_descr;
+
+   gdt_descr.address = (long)get_cpu_direct_gdt(cpu);
+   gdt_descr.size = GDT_SIZE - 1;
+   load_gdt(_descr);
+}
+EXPORT_SYMBOL(load_direct_gdt);
+
 /* Load a fixmap remapping of the per-cpu GDT */
 void load_fixmap_gdt(int cpu)
 {
@@ -460,6 +478,7 @@ void load_fixmap_gdt(int cpu)

Re: [Xen-devel] [PATCH v2 3/8] hw: Default -drive to if=none instead of ide when ide cannot work

2017-01-26 Thread Laurent Vivier 
Le 26/01/2017 à 16:09, Markus Armbruster a écrit :
> Block backends defined with -drive if=ide are meant to be picked up by
> machine initialization code: a suitable frontend gets created and
> wired up automatically.
> 
> if=ide drives not picked up that way can still be used with -device as
> if they had if=none, but that's unclean and best avoided.  Unused ones
> produce an "Orphaned drive without device" warning.
> 
> -drive parameter "if" is optional, and the default depends on the
> machine type.  If a machine type doesn't specify a default, the
> default is "ide".
> 
> Many machine types implicitly default to if=ide that way, even though
> they don't actually have an IDE controller.  This makes no sense.
> 
> Change the implicit default to if=none.  Affected machines:
> 
> * all targets: none
> * aarch64/arm: akita ast2500 canon cheetah collie connex imx25
>   integratorcp kzm lm3s6965evb lm3s811evb mainstone musicpal n800 n810
>   netduino2 nuri palmetto realview romulus sabrelite smdkc210 sx1 sx1
>   verdex z2
> * cris: axis-dev88
> * i386/x86_64: xenpv
> * lm32: lm32-evr lm32-uclinux milkymist
> * m68k: an5206 dummy mcf5208evb
> * microblaze/microblazeel: petalogix-ml605 petalogix-s3adsp1800
> * mips/mips64/mips64el/mipsel: mipssim
> * moxie: moxiesim
> * or32: or32-sim
> * ppc/ppc64/ppcemb: bamboo ref405ep taihu virtex-ml507
> * ppc/ppc64: mpc8544ds ppce500
> * sh4/sh4eb: shix
> * sparc: leon3_generic
> * sparc64: niagara
> * tricore: tricore_testboard
> * unicore32: puv3
> * xtensa/xtensaeb: kc705 lx200 lx60 ml605 sim
> 
> None of these machines have an IDE controller, let alone code to
> honor if=ide.
> 
> Cc: Peter Maydell 
> Cc: qemu-...@nongnu.org
> Cc: Edgar E. Iglesias 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: xen-de...@lists.xensource.com
> Cc: Michael Walle 
> Cc: Laurent Vivier 
> Cc: Anthony Green 
> Cc: Jia Liu 
> Cc: Alexander Graf 
> Cc: qemu-...@nongnu.org
> Cc: Magnus Damm 
> Cc: Fabien Chouteau 
> Cc: Mark Cave-Ayland 
> Cc: Artyom Tarasenko 
> Cc: Bastian Koppelmann 
> Cc: Guan Xuetao 
> Cc: Max Filippov 
> Signed-off-by: Markus Armbruster 
> Acked-By: Artyom Tarasenko 
> ---
>  include/sysemu/blockdev.h | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/include/sysemu/blockdev.h b/include/sysemu/blockdev.h
> index 16432f3..351a039 100644
> --- a/include/sysemu/blockdev.h
> +++ b/include/sysemu/blockdev.h
> @@ -19,12 +19,11 @@ void blockdev_auto_del(BlockBackend *blk);
>  typedef enum {
>  IF_DEFAULT = -1,/* for use with drive_add() only */
>  /*
> - * IF_IDE must be zero, because we want MachineClass member
> - * block_default_type to default-initialize to IF_IDE
> + * IF_NONE must be zero, because we want MachineClass member
> + * block_default_type to default-initialize to IF_NONE
>   */
> -IF_IDE = 0,
> -IF_NONE,
> -IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
> +IF_NONE = 0,
> +IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
>  IF_COUNT
>  } BlockInterfaceType;
>  
> 
Reviewed-by: Laurent Vivier 


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

[Xen-devel] [PATCH] xen: sched: improve debug dump output.

2017-01-26 Thread Dario Faggioli 
Scheduling information debug dump for Credit2 is hard
to read as it contains the same information repeated
multiple time in different ways.

In fact, in Credit2, CPUs are grouped in runqueus.
Here's the current debug output:

 CPU[00]  sibling=,0003, core=,00ff
run: [32767.0] flags=0 cpu=0 credit=-1073741824 [w=0] load=0 (~0%)
  1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
  2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)
 CPU[01]  sibling=,0003, core=,00ff
run: [32767.1] flags=0 cpu=1 credit=-1073741824 [w=0] load=0 (~0%)
  1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
  2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)
 CPU[02]  sibling=,000c, core=,00ff
run: [0.2] flags=2 cpu=2 credit=3556909 [w=256] load=262144 (~100%)
  1: [0.3] flags=0 cpu=2 credit=3273410 [w=256] load=262144 (~100%)
  2: [0.4] flags=0 cpu=2 credit=2974954 [w=256] load=262144 (~100%)

Here, CPUs 0, 1 and 2, are all part of runqueue 0,
the content of which (which, BTW, is d0v3 and d0v4)
is printed 3 times! It is also not very useful to
see the details of the idle vcpus, as they're always
the same (except for the vCPU ids).

With this change, we print:
 - pCPUs details and, for non idle ones, what vCPU
   they're running;
 - the runqueue content, once and for all.

 Runqueue 0:
 CPU[00] runq=0, sibling=,0003, core=,00ff
run: [0.15] flags=2 cpu=0 credit=5804742 [w=256] load=3655 (~1%)
 CPU[01] runq=0, sibling=,0003, core=,00ff
 CPU[02] runq=0, sibling=,000c, core=,00ff
run: [0.3] flags=2 cpu=2 credit=6674856 [w=256] load=262144 (~100%)
 CPU[03] runq=0, sibling=,000c, core=,00ff
 RUNQ:
  0: [0.1] flags=0 cpu=2 credit=6561215 [w=256] load=262144 (~100%)
  1: [0.2] flags=0 cpu=2 credit=5812356 [w=256] load=262144 (~100%)

Stop printing details of idle vCPUs also in Credit1
and RTDS (they're pretty useless in there too).

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: Meng Xu 
---
 xen/common/sched_credit.c  |6 ++--
 xen/common/sched_credit2.c |   72 +---
 xen/common/sched_rt.c  |9 +-
 xen/common/schedule.c  |7 ++--
 4 files changed, 49 insertions(+), 45 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index ad20819..7c0ff47 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1988,13 +1988,13 @@ csched_dump_pcpu(const struct scheduler *ops, int cpu)
 runq = >runq;
 
 cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_sibling_mask, cpu));
-printk(" sort=%d, sibling=%s, ", spc->runq_sort_last, cpustr);
+printk("CPU[%02d] sort=%d, sibling=%s, ", cpu, spc->runq_sort_last, 
cpustr);
 cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
 printk("core=%s\n", cpustr);
 
-/* current VCPU */
+/* current VCPU (nothing to say if that's the idle vcpu). */
 svc = CSCHED_VCPU(curr_on_cpu(cpu));
-if ( svc )
+if ( svc && !is_idle_vcpu(svc->vcpu) )
 {
 printk("\trun: ");
 csched_dump_vcpu(svc);
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b2f2b17..c4e2b9a 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2627,56 +2627,25 @@ csched2_dump_vcpu(struct csched2_private *prv, struct 
csched2_vcpu *svc)
 printk("\n");
 }
 
-static void
-csched2_dump_pcpu(const struct scheduler *ops, int cpu)
+static inline void
+dump_pcpu(const struct scheduler *ops, int cpu)
 {
 struct csched2_private *prv = CSCHED2_PRIV(ops);
-struct list_head *runq, *iter;
 struct csched2_vcpu *svc;
-unsigned long flags;
-spinlock_t *lock;
-int loop;
 #define cpustr keyhandler_scratch
 
-/*
- * We need both locks:
- * - csched2_dump_vcpu() wants to access domains' weights,
- *   which are protected by the private scheduler lock;
- * - we scan through the runqueue, so we need the proper runqueue
- *   lock (the one of the runqueue this cpu is associated to).
- */
-read_lock_irqsave(>lock, flags);
-lock = per_cpu(schedule_data, cpu).schedule_lock;
-spin_lock(lock);
-
-runq = (ops, cpu)->runq;
-
 cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_sibling_mask, cpu));
-printk(" sibling=%s, ", cpustr);
+printk("CPU[%02d] runq=%d, sibling=%s, ", cpu, c2r(ops, cpu), cpustr);
 cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
 printk("core=%s\n", cpustr);
 
-/* current VCPU */
+/* current VCPU (nothing to say if that's the idle vcpu) */
 svc = CSCHED2_VCPU(curr_on_cpu(cpu));
-if ( svc )
+if

Re: [Xen-devel] [PATCH 5/7] fuzz/x86emul: update fuzzer

2017-01-26 Thread George Dunlap 
On 26/01/17 14:33, Jan Beulich wrote:
 +return X86EMUL_EXCEPTION;
 +else
 +{
 +if ( input.data[data_index] > 0xc )
 +rc = X86EMUL_EXCEPTION;
 +else if ( input.data[data_index] > 0x8 )
 +rc = X86EMUL_UNHANDLEABLE;
>>>
>>> How were these numbers chosen?
>>
>> The idea here is to give the fuzzer a way of (blindly) changing whether
>> the operation succeeds or how it fails in a "modular" way, by just
>> "consuming" one byte from the input.  The numbers are meant to make
>> random values roughly 50% succeed, 25% generate an exception, and 25%
>> return unhandleable.
> 
> But the vast majority of cases would fall in the exception group. Did
> you perhaps mean 0xc0 and 0x80 then? In any event a comment
> would be nice to clarify the intention.

Oh, yes -- that should definitely be 0xc0 and 0x80. :-)

 +static int fuzz_cpuid(
 +uint32_t leaf,
 +uint32_t subleaf,
 +struct cpuid_leaf *res,
 +struct x86_emulate_ctxt *ctxt)
 +{
 +int rc;
 +
 +rc = maybe_fail("cpuid", true);
 +
 +if ( rc == X86EMUL_OKAY )
 +emul_test_cpuid(leaf, subleaf, res, ctxt);
 +
 +return rc;
 +}
>>>
>>> Careful here: ->cpuid() is documented to only be allowed to fail with
>>> X86EMUL_EXCEPTION.
>>
>> But at the moment, the emulator seems to function properly even if you
>> return UNHANDLEABLE.  This is probably more robust than otherwise.
> 
> Hmm, yes and no. Considering it being documented that way,
> someone adding an ASSERT() to that effect would be a legitimate
> thing to do, yet would result in aborts for suitable input here.

Yes.  And I think that makes sense for how I was running it initially,
where the main person running it knows the delta between what is
"officially" required and what is actually required.  But that probably
needs revisiting.

I still think that knowing empirically what the emulation code will
accept (as opposed to what it's supposed to accept) is a useful thing,
but false positives aren't free.  If we had a list somewhere of the
places we deviate from the spec, it would be easier to determine if a
particular crash was a false positive or not.

I'll leave it for Wei now to decide whether he wants to document
deviations or just follow the spec in this instance.

 + */
 +void sanitize_input(struct x86_emulate_ctxt *ctxt) {
 +struct cpu_user_regs *regs = 
 +unsigned long bitmap = input.options;
 +
 +input.options &=
 +~((1<>>
>>> Ah, this addresses one of the earlier remarks. However, ->write
>>> and ->cmpxchg have become optional a little while ago.
>>
>> And yet, empirically, the emulator crashes if you don't have them.  If
>> this isn't expected, we should submit some patches.
> 
> Is that the case now, or was that when you wrote this code
> (before 4.8 went out)? As said, the change isn't all that old.

Oh, right -- I interpreted "a little while ago" as >6 months. :-)  Yes,
if it's supposed to handle not having write and cmpxchg, then we should
test not having them.

 -George


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

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

2017-01-26 Thread osstest service owner 
flight 104711 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104711/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 465663e9f128428323e6c6e4431dd15ac287a24c
baseline version:
 ovmf c1b0828b3ba8fa203033ede0c3329c0d5573719e

Last test of basis   104689  2017-01-26 05:46:19 Z0 days
Testing same since   104711  2017-01-26 14:45:09 Z0 days1 attempts


People who touched revisions under test:
  Bhupesh Sharma 
  Bhupesh Sharma 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=465663e9f128428323e6c6e4431dd15ac287a24c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
465663e9f128428323e6c6e4431dd15ac287a24c
+ branch=ovmf
+ revision=465663e9f128428323e6c6e4431dd15ac287a24c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x465663e9f128428323e6c6e4431dd15ac287a24c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ :

[Xen-devel] [OSSTEST PATCH] bisection: Really avoid flail

2017-01-26 Thread Ian Jackson 
The flail detector needs to search for flights which will look like
the one it is creating, when this one is done.  The intended blessing
always lacks `-bisect' so is no use.

We can use the last blessing for this: both cr-try-bisect and
cr-try-bisect-adhoc pass the same value for the last blessing and for
the 2nd parameter to perhaps_bisect_step_core (which is passed to
sg-execute flight to properly bless the flight when it's done).

Signed-off-by: Ian Jackson 
---
 cs-bisection-step | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/cs-bisection-step b/cs-bisection-step
index 819e519..a0ceaa7 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -8,6 +8,16 @@
 #   ./cs-bisection-setup []   
 # options, usually:
 #  --blessings=real,real-bisect
+#
+# First entry in --blessings list is the blessing of the basis
+# (non-bisection) flights.  This should not be the same as the
+# blessing which will be applied to the bisection flights when they
+# are complete, as otherwise the "basis repro" will retrigger when
+# this is not desirable.
+#
+# Last entry in --blessings should be blessing which will be
+# applied to this flight when it is finished.  This is used for flail
+# detection.
 
 # This is part of "osstest", an automated testing framework for Xen.
 # Copyright (C) 2009-2013 Citrix Inc.
@@ -1335,9 +1345,7 @@ END
 SELECT flight, blessing, started FROM flights
WHERE branch=?
   AND $restrictflight_cond
-  AND blessing = (
-   SELECT intended FROM flights WHERE flight = ?
-)
+  AND blessing = ?
  AND NOT EXISTS (
SELECT 1
  FROM $runvarsqt1 r1 FULL OUTER JOIN
@@ -1368,7 +1376,8 @@ END
 $minflight //= 0;
print DEBUG "minflight=$minflight\n";
 
-   $equalflightsq->execute($branch, $popflight, $popflight, $minflight);
+   $equalflightsq->execute($branch, $blessings[$#blessings],
+$popflight, $minflight);
my $nequalflights = 0;
my $explanation = '';
while (my $identical = $equalflightsq->fetchrow_hashref()) {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

2017-01-26 Thread Roger Pau Monne 
On Thu, Jan 26, 2017 at 04:43:37AM -0700, Jan Beulich wrote:
> >>> On 19.01.17 at 18:29,  wrote:
> > --- a/xen/arch/x86/domain_build.c
> > +++ b/xen/arch/x86/domain_build.c
> > @@ -191,11 +191,40 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain 
> > *dom0)
> >  }
> >  
> >  #ifdef CONFIG_SHADOW_PAGING
> > -static bool_t __initdata opt_dom0_shadow;
> > +bool __initdata opt_dom0_shadow;
> >  boolean_param("dom0_shadow", opt_dom0_shadow);
> >  #else
> > -#define opt_dom0_shadow 0
> > +#define opt_dom0_shadow false
> 
> No need to duplicate the #define from the header here.
> 
> > @@ -1008,12 +1037,8 @@ int __init construct_dom0(
> >  paddr_t mpt_alloc;
> >  
> >  /* Sanity! */
> > -BUG_ON(d->domain_id != 0);
> > -BUG_ON(d->vcpu[0] == NULL);
> >  BUG_ON(v->is_initialised);
> 
> What about this last one?

Hm, not sure why I didn't move that last time, IIRC it triggered for PVHv2
vCPU, but that no longer seems to be the case, so I've moved it. Both fixed,
thanks.

Roger.

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

Re: [Xen-devel] [PATCH] x86/dmar: place the initdata annotation after the variable type

2017-01-26 Thread Jan Beulich 
>>> On 26.01.17 at 17:18,  wrote:
> clang cannot cope with the annotation being in the middle of the variable
> declaration.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -871,8 +871,8 @@ struct user_rmrr {
>  u32 sbdf[MAX_USER_RMRR_DEV];
>  };
>  
> -static __initdata unsigned int nr_rmrr;
> -static struct __initdata user_rmrr user_rmrrs[MAX_USER_RMRR];
> +static unsigned int __initdata nr_rmrr;
> +static struct user_rmrr __initdata user_rmrrs[MAX_USER_RMRR];

I'm sorry for not spotting this during review - while I wasn't aware
that this actively breaks clang, it's still stylistically better even with
gcc. I'm surprised though that (by implication) these are the only
offenders in our tree.

Jan

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

Re: [Xen-devel] [PATCH] x86/dmar: place the initdata annotation after the variable type

2017-01-26 Thread Andrew Cooper 
On 26/01/17 16:18, Roger Pau Monne wrote:
> clang cannot cope with the annotation being in the middle of the variable
> declaration.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH] x86/dmar: place the initdata annotation after the variable type

2017-01-26 Thread Roger Pau Monne 
clang cannot cope with the annotation being in the middle of the variable
declaration.

Signed-off-by: Roger Pau Monné 
---
Cc: Kevin Tian 
Cc: Feng Wu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/drivers/passthrough/vtd/dmar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 831fe1a..4a6a819 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -871,8 +871,8 @@ struct user_rmrr {
 u32 sbdf[MAX_USER_RMRR_DEV];
 };
 
-static __initdata unsigned int nr_rmrr;
-static struct __initdata user_rmrr user_rmrrs[MAX_USER_RMRR];
+static unsigned int __initdata nr_rmrr;
+static struct user_rmrr __initdata user_rmrrs[MAX_USER_RMRR];
 
 /* Macro for RMRR inclusive range formatting. */
 #define ERMRRU_FMT "[%lx-%lx]"
-- 
2.10.1 (Apple Git-78)


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

[Xen-devel] [xen-unstable-smoke test] 104716: regressions - trouble: blocked/broken/fail

2017-01-26 Thread osstest service owner 
flight 104716 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104716/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-buildfail REGR. vs. 104630
 build-armhf   5 xen-buildfail REGR. vs. 104630

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  91f59d2041b0f2760da082827bcea57648845cc1
baseline version:
 xen  c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc

Last test of basis   104630  2017-01-24 19:01:56 Z1 days
Failing since104642  2017-01-25 10:01:54 Z1 days   28 attempts
Testing same since   104648  2017-01-25 15:01:38 Z1 days   25 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Dario Faggioli 
  Elena Ufimtseva 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Praveen Kumar 
  Roger Pau Monné 
  Tim Deegan 
  Venu Busireddy 
  Wei Liu 

jobs:
 build-amd64  fail
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt 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.

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

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

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

2017-01-26 Thread Razvan Cojocaru 
On 01/26/2017 06:00 PM, Dario Faggioli wrote:
> On Thu, 2017-01-26 at 17:42 +0200, Razvan Cojocaru wrote:
>> On 01/26/2017 05:14 PM, Dario Faggioli wrote:
>>> You mean you'd want to implement xc_vcpu_pause() by means of
>>> the XEN_DOMCTL_gdbsx_pausevcpu?
>>>
>>> What's the use case for that, and does it fit with the
>>> implementation
>>> of said hypercall (which, e.g., requires that the domain is already
>>> paused)?
>>
>> Not necessarily implement xc_vcpu_pause() by means of
>> XEN_DOMCTL_gdbsx_pausevcpu, it's just that from a design perspective
>> this seems rather specialised - the domctl name suggests that this is
>> only useful for debugging, and it also hardcodes an implementation
>> for
>> calling that hypercall in xg_main.c, whereas pausing a single VCPU is
>> a
>> generic operation that other clients, as well as the debugger, might
>> find worthwhile to do.
>>
> And, in principle, I agree that it would make sense to have a generic
> vCPU pause/unpause API.
> 
> Outside of principle --a.k.a., in practise-- I'm not sure whether it
> really makes sense, and whether it would actually work.
> 
> I'm thinking of how happy a guest would be to be running with one of
> it's (v)CPU frozen, and am wondering whether this could cause it to
> panic, or behave funnily.
> 
> But I haven't tried, of course.
> 
>> Does XEN_DOMCTL_gdbsx_pausevcpu require that the whole domain is
>> paused
>> (for longer that the duration of the actual hypercall)?
>>
> AFAICT, it does. See the implementation of the hypercall:
> 
> if ( !d->controller_pause_count )
> break;
> ret = -EINVAL;
> if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= d->max_vcpus ||
>  (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
> break;
> ret = vcpu_pause_by_systemcontroller(v);
> 
> See commit 680d79f10 ("x86/gdbsx: invert preconditions for
> XEN_DOMCTL_gdbsx_{,un}pausevcpu hypercalls":
> 
> Revert back to how it was originally, i.e. the 
> XEN_DOMCTL_gdbsx_{,un}pausevcpu
> hypercalls are only valid for a domain already paused by the system 
> controller.
> 
> And see how it's used, e.g., as described in the comment above
> xg_step() (or even in its actual code):
> 
> /*
>  * Single step the given vcpu. This is achieved by pausing all but given 
> vcpus,
>  * setting the TF flag, let the domain run and pause, unpause all vcpus, and
>  * clear TF flag on given vcpu.
>  * Returns: 0 success
>  */

Right. Thank you for clearing that up!


Thanks,
Razvan

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

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

2017-01-26 Thread Dario Faggioli 
On Thu, 2017-01-26 at 17:42 +0200, Razvan Cojocaru wrote:
> On 01/26/2017 05:14 PM, Dario Faggioli wrote:
> > You mean you'd want to implement xc_vcpu_pause() by means of
> > the XEN_DOMCTL_gdbsx_pausevcpu?
> > 
> > What's the use case for that, and does it fit with the
> > implementation
> > of said hypercall (which, e.g., requires that the domain is already
> > paused)?
> 
> Not necessarily implement xc_vcpu_pause() by means of
> XEN_DOMCTL_gdbsx_pausevcpu, it's just that from a design perspective
> this seems rather specialised - the domctl name suggests that this is
> only useful for debugging, and it also hardcodes an implementation
> for
> calling that hypercall in xg_main.c, whereas pausing a single VCPU is
> a
> generic operation that other clients, as well as the debugger, might
> find worthwhile to do.
> 
And, in principle, I agree that it would make sense to have a generic
vCPU pause/unpause API.

Outside of principle --a.k.a., in practise-- I'm not sure whether it
really makes sense, and whether it would actually work.

I'm thinking of how happy a guest would be to be running with one of
it's (v)CPU frozen, and am wondering whether this could cause it to
panic, or behave funnily.

But I haven't tried, of course.

> Does XEN_DOMCTL_gdbsx_pausevcpu require that the whole domain is
> paused
> (for longer that the duration of the actual hypercall)?
> 
AFAICT, it does. See the implementation of the hypercall:

if ( !d->controller_pause_count )
break;
ret = -EINVAL;
if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= d->max_vcpus ||
 (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) == NULL )
break;
ret = vcpu_pause_by_systemcontroller(v);

See commit 680d79f10 ("x86/gdbsx: invert preconditions for
XEN_DOMCTL_gdbsx_{,un}pausevcpu hypercalls":

Revert back to how it was originally, i.e. the 
XEN_DOMCTL_gdbsx_{,un}pausevcpu
hypercalls are only valid for a domain already paused by the system 
controller.

And see how it's used, e.g., as described in the comment above
xg_step() (or even in its actual code):

/*
 * Single step the given vcpu. This is achieved by pausing all but given vcpus,
 * setting the TF flag, let the domain run and pause, unpause all vcpus, and
 * clear TF flag on given vcpu.
 * Returns: 0 success
 */

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

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2 3/8] hw: Default -drive to if=none instead of ide when ide cannot work

2017-01-26 Thread Thomas Huth 
On 26.01.2017 16:09, Markus Armbruster wrote:
> Block backends defined with -drive if=ide are meant to be picked up by
> machine initialization code: a suitable frontend gets created and
> wired up automatically.
> 
> if=ide drives not picked up that way can still be used with -device as
> if they had if=none, but that's unclean and best avoided.  Unused ones
> produce an "Orphaned drive without device" warning.
> 
> -drive parameter "if" is optional, and the default depends on the
> machine type.  If a machine type doesn't specify a default, the
> default is "ide".
> 
> Many machine types implicitly default to if=ide that way, even though
> they don't actually have an IDE controller.  This makes no sense.
> 
> Change the implicit default to if=none.  Affected machines:
> 
> * all targets: none
> * aarch64/arm: akita ast2500 canon cheetah collie connex imx25
>   integratorcp kzm lm3s6965evb lm3s811evb mainstone musicpal n800 n810
>   netduino2 nuri palmetto realview romulus sabrelite smdkc210 sx1 sx1
>   verdex z2
> * cris: axis-dev88
> * i386/x86_64: xenpv
> * lm32: lm32-evr lm32-uclinux milkymist
> * m68k: an5206 dummy mcf5208evb
> * microblaze/microblazeel: petalogix-ml605 petalogix-s3adsp1800
> * mips/mips64/mips64el/mipsel: mipssim
> * moxie: moxiesim
> * or32: or32-sim
> * ppc/ppc64/ppcemb: bamboo ref405ep taihu virtex-ml507
> * ppc/ppc64: mpc8544ds ppce500
> * sh4/sh4eb: shix
> * sparc: leon3_generic
> * sparc64: niagara
> * tricore: tricore_testboard
> * unicore32: puv3
> * xtensa/xtensaeb: kc705 lx200 lx60 ml605 sim
> 
> None of these machines have an IDE controller, let alone code to
> honor if=ide.
> 
> Cc: Peter Maydell 
> Cc: qemu-...@nongnu.org
> Cc: Edgar E. Iglesias 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: xen-de...@lists.xensource.com
> Cc: Michael Walle 
> Cc: Laurent Vivier 
> Cc: Anthony Green 
> Cc: Jia Liu 
> Cc: Alexander Graf 
> Cc: qemu-...@nongnu.org
> Cc: Magnus Damm 
> Cc: Fabien Chouteau 
> Cc: Mark Cave-Ayland 
> Cc: Artyom Tarasenko 
> Cc: Bastian Koppelmann 
> Cc: Guan Xuetao 
> Cc: Max Filippov 
> Signed-off-by: Markus Armbruster 
> Acked-By: Artyom Tarasenko 
> ---
>  include/sysemu/blockdev.h | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/include/sysemu/blockdev.h b/include/sysemu/blockdev.h
> index 16432f3..351a039 100644
> --- a/include/sysemu/blockdev.h
> +++ b/include/sysemu/blockdev.h
> @@ -19,12 +19,11 @@ void blockdev_auto_del(BlockBackend *blk);
>  typedef enum {
>  IF_DEFAULT = -1,/* for use with drive_add() only */
>  /*
> - * IF_IDE must be zero, because we want MachineClass member
> - * block_default_type to default-initialize to IF_IDE
> + * IF_NONE must be zero, because we want MachineClass member
> + * block_default_type to default-initialize to IF_NONE
>   */
> -IF_IDE = 0,
> -IF_NONE,
> -IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
> +IF_NONE = 0,
> +IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
>  IF_COUNT
>  } BlockInterfaceType;
>  
> 

Makes sense.

Reviewed-by: Thomas Huth 


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

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

2017-01-26 Thread Jan Beulich 
>>> On 26.01.17 at 13:08,  wrote:
> I see that there's currently no xc_vcpu_pause() (there's only
> xc_domain_pause(), which freezes all the VCPUs), but there's
> XEN_DOMCTL_gdbsx_pausevcpu, which is only used by
> tools/debugger/gdbsx/xg/xg_main.c.
> 
> Wouldn't it make sense to have a "regular" DOMCTL in libxc that the
> debugger, as well as other clients, would make use of (said
> xc_vcpu_pause() / xc_vcpu_unpause())?

I could imagine the main reason for it to not exist being that using
it may confuse the guest (seeing one or more of its vCPU-s no
longer respond for some arbitrary time period).

Jan


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

Re: [Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

2017-01-26 Thread Jan Beulich 
>>> On 26.01.17 at 15:50,  wrote:
> From: David Woodhouse 
> 
> For some MMIO regions, such as those high above RAM, mfn_valid() will
> return false.
> 
> Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce
> consistent cachability of MMIO mappings"), guests have no longer been
> able to use PAT to obtain write-combining on such regions because the
> 'ignore PAT' bit is set in EPT.
> 
> We probably want to err on the side of caution and preserve that
> behaviour for addresses in mmio_ro_ranges, but not for normal MMIO
> mappings. That necessitates a slight refactoring to check mfn_valid()
> later, and let the MMIO case get through to the right code path.
> 
> Since we're not bailing out for !mfn_valid() immediately, the range
> checks need to be adjusted to cope — simply by masking in the low bits
> to account for 'order' instead of adding, to avoid overflow when the mfn
> is INVALID_MFN (which happens on unmap, since we carefully call this
> function to fill in the EMT even though the PTE won't be valid).
> 
> The range checks are also slightly refactored to put only one of them in
> the fast path in the common case. If it doesn't overlap, then it
> *definitely* isn't contained, so we don't need both checks. And if it
> overlaps and is only one page, then it definitely *is* contained.
> 
> Finally, add a comment clarifying how that 'return -1' works — it isn't
> returning an error and causing the mapping to fail; it relies on
> resolve_misconfig() being able to split the mapping later. So it's
> *only* sane to do it where order>0 and the 'problem' will be solved by
> splitting the large page. Not for blindly returning 'error', which I was
> tempted to do in my first attempt.
> 
> Signed-off-by: David Woodhouse 

Reviewed-by: Jan Beulich 

But before committing I'd prefer to have a VMX maintainer ack
too.

Jan

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

Re: [Xen-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen

2017-01-26 Thread Roger Pau Monné 
On Wed, Jan 25, 2017 at 11:05:29AM +, Roger Pau Monné wrote:
> On Tue, Jan 24, 2017 at 01:30:02PM -0800, Stefano Stabellini wrote:
> > On Tue, 24 Jan 2017, Stefano Stabellini wrote:
> > > On Tue, 24 Jan 2017, Roger Pau Monné wrote:
> > > > Hello,
> > > > 
> > > > The following commit:
> > > > 
> > > > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894
> > > > Author: Juergen Gross 
> > > > Date:   Tue Nov 22 07:10:58 2016 +0100
> > > > 
> > > > xen: create qdev for each backend device
> > > > 
> > > > Prevents me from running QEMU on FreeBSD/Xen, the following is printed 
> > > > on the
> > > > QEMU log:
> > > > 
> > > > char device redirected to /dev/pts/2 (label serial0)
> > > > xen be core: xen be core: can't open gnttab device
> > > > can't open gnttab device
> > > > xen be core: xen be core: can't open gnttab device
> > > > can't open gnttab device
> > > > 
> > > > # xl create -c ~/domain.cfg
> > > > Parsing config from /root/domain.cfg
> > > > libxl: error: libxl_dm.c:2201:device_model_spawn_outcome: Domain 
> > > > 32:domain 32 device model: spawn failed (rc=-3)
> > > > libxl: error: libxl_create.c:1506:domcreate_devmodel_started: Domain 
> > > > 32:device model did not start: -3
> > > > libxl: error: libxl_dm.c:2315:kill_device_model: Device Model already 
> > > > exited
> > > > libxl: error: libxl.c:1572:libxl__destroy_domid: Domain 32:Non-existant 
> > > > domain
> > > > libxl: error: libxl.c:1531:domain_destroy_callback: Domain 32:Unable to 
> > > > destroy guest
> > > > libxl: error: libxl.c:1458:domain_destroy_cb: Domain 32:Destruction of 
> > > > domain failed
> > > > # cat /var/log/xen/qemu-dm-domain.log
> > > > char device redirected to /dev/pts/2 (label serial0)
> > > > xen be core: xen be core: can't open gnttab device
> > > > can't open gnttab device
> > > > xen be core: xen be core: can't open gnttab device
> > > > can't open gnttab device
> > > > 
> > > > I'm not really familiar with any of that code, but I think that using
> > > > qdev_init_nofail is wrong, since on FreeBSD/Xen for example we don't yet
> > > > support the gnttab device, so initialization of the Xen Qdisk backend 
> > > > can fail
> > > > (and possibly the same applies to Linux if someone decides to compile a 
> > > > kernel
> > > > without the gnttab device). Yet QEMU can be used without the Qdisk 
> > > > backend.
> > > 
> > > How did you manage to configure QEMU before? The configure script had
> > > xc_gnttab_open calls in it up to Xen 4.6.
> > 
> > I know the answer! Because the configure script only compiles the code,
> > doesn't try to run it. xc_gnttab_open compiled correctly but returned
> > error when executed. Is that right?
> 
> Yes, I'm quite that's right. FreeBSD is using gnttab_unimp.c, which implements
> xengnttab_open, so compilation will not fail.
> 
> > 
> > 
> > > I am happy to support a use case where the kernel doesn't have gntdev,
> > > but it needs to be explicit: we need to detect it in the configure
> > > script, then avoid the initialization of devices which require it.
> > 
> > I would still prefer configure to be able to detect this case. If it
> > cannot be made to detect it, then we can try to figure out a way to
> > catch the initialization errors at run time. 
> 
> I think it's better to simply fail to initialize Xen Qdisk at runtime, or else
> a xen-tools/QEMU compiled on a non-Xen environment won't get gnttab and as a
> consequence Xen Qdisk support enabled, and I think it's quite common for
> distros to compile Xen packages on non-Xen environments (where /dev/xen/gnttab
> is not available).

Ping?

I'm not really sure how to solve this because I have zero experience with QEMU
internals (all this qdev stuff). Can we restore the previous behavior, where
the failure to initialize a device wouldn't prevent QEMU from starting?

Roger.

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

Re: [Xen-devel] POSIX error names and codes in PV protocols

2017-01-26 Thread Jan Beulich 
>>> On 26.01.17 at 15:40,  wrote:
> There is some work happening on new PV protocols: sndif [1],
> 
> displif [2], PV calls [3] and the common part of those is that
> 
> error/status codes must be returned as a part of a response packet.
> 
> For that Konrad suggested [1] (and Stefano already used in [3]) POSIX
> 
> to be employed here instead of defining protocol specific error codes.
> 
> The problem I see here is that POSIX only defines names of the errors,
> 
> but not values [4]. So, in order to use POSIX one still needs to define
> 
> the values (names must be the same, but values may differ for different 
> OSes).
> 
> So, the question is what would be the best option to
> 
> a) have those numbers defined in OS agnostic way
> 
> b) have those defined for all PV protocols
> 
> Stefano has already defined the error code values in his work [3],
> 
> but for other protocols this should be reimplemented again.

Aren't these simply what public/errno.h provides? Why would any
Xen specific protocol want to define their own, now that we have
this base set?

Jan


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

[Xen-devel] [xen-unstable-smoke test] 104713: regressions - trouble: blocked/broken/fail

2017-01-26 Thread osstest service owner 
flight 104713 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104713/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-buildfail REGR. vs. 104630
 build-armhf   5 xen-buildfail REGR. vs. 104630

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  91f59d2041b0f2760da082827bcea57648845cc1
baseline version:
 xen  c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc

Last test of basis   104630  2017-01-24 19:01:56 Z1 days
Failing since104642  2017-01-25 10:01:54 Z1 days   27 attempts
Testing same since   104648  2017-01-25 15:01:38 Z1 days   24 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Dario Faggioli 
  Elena Ufimtseva 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Praveen Kumar 
  Roger Pau Monné 
  Tim Deegan 
  Venu Busireddy 
  Wei Liu 

jobs:
 build-amd64  fail
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt 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.

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

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

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

2017-01-26 Thread Razvan Cojocaru 
On 01/26/2017 05:14 PM, Dario Faggioli wrote:
> [Adding tools people, and Andrew's which, according to git history,
>  has touched the involved (Xen) code for last :-) ]
> 
> On Thu, 2017-01-26 at 14:08 +0200, Razvan Cojocaru wrote:
>> Hello,
>>
>> I see that there's currently no xc_vcpu_pause() (there's only
>> xc_domain_pause(), which freezes all the VCPUs), but there's
>> XEN_DOMCTL_gdbsx_pausevcpu, which is only used by
>> tools/debugger/gdbsx/xg/xg_main.c.
>>
>> Wouldn't it make sense to have a "regular" DOMCTL in libxc that the
>> debugger, as well as other clients, would make use of (said
>> xc_vcpu_pause() / xc_vcpu_unpause())?
>>
> You mean you'd want to implement xc_vcpu_pause() by means of
> the XEN_DOMCTL_gdbsx_pausevcpu?
> 
> What's the use case for that, and does it fit with the implementation
> of said hypercall (which, e.g., requires that the domain is already
> paused)?

Not necessarily implement xc_vcpu_pause() by means of
XEN_DOMCTL_gdbsx_pausevcpu, it's just that from a design perspective
this seems rather specialised - the domctl name suggests that this is
only useful for debugging, and it also hardcodes an implementation for
calling that hypercall in xg_main.c, whereas pausing a single VCPU is a
generic operation that other clients, as well as the debugger, might
find worthwhile to do.

As for a use case, an introspection application might be interested in
briefly pausing a VCPU while it inspects data related to it.

Does XEN_DOMCTL_gdbsx_pausevcpu require that the whole domain is paused
(for longer that the duration of the actual hypercall)?


Thanks,
Razvan

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

[Xen-devel] [xen-4.3-testing baseline-only test] 68466: tolerable trouble: blocked/broken/fail/pass

2017-01-26 Thread Platform Team regression test user 
This run is configured for baseline tests only.

flight 68466 xen-4.3-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68466/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl19 guest-start/debian.repeat fail baseline untested
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail baseline 
untested
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install   fail baseline untested
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-invlpg~hapfail   never pass
 test-xtf-amd64-amd64-1   20 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-5   19 xtf/test-hvm32-invlpg~hapfail   never pass
 test-xtf-amd64-amd64-5   20 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-1   26 xtf/test-hvm32-xsa-188   fail   never pass
 test-xtf-amd64-amd64-1   28 xtf/test-hvm32-xsa-192   fail   never pass
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-invlpg~hapfail   never pass
 test-xtf-amd64-amd64-5   26 xtf/test-hvm32-xsa-188   fail   never pass
 test-xtf-amd64-amd64-2   20 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-5   28 xtf/test-hvm32-xsa-192   fail   never pass
 test-xtf-amd64-amd64-1   35 xtf/test-hvm32pae-xsa-188fail   never pass
 test-xtf-amd64-amd64-2   26 xtf/test-hvm32-xsa-188   fail   never pass
 test-xtf-amd64-amd64-1   39 xtf/test-hvm32pse-xsa-188fail   never pass
 test-xtf-amd64-amd64-2   28 xtf/test-hvm32-xsa-192   fail   never pass
 test-xtf-amd64-amd64-1 41 xtf/test-hvm64-fpu-exception-emulation fail never 
pass
 test-xtf-amd64-amd64-5   35 xtf/test-hvm32pae-xsa-188fail   never pass
 test-xtf-amd64-amd64-5   39 xtf/test-hvm32pse-xsa-188fail   never pass
 test-xtf-amd64-amd64-2   35 xtf/test-hvm32pae-xsa-188fail   never pass
 test-xtf-amd64-amd64-5 41 xtf/test-hvm64-fpu-exception-emulation fail never 
pass
 test-xtf-amd64-amd64-1   51 xtf/test-hvm64-xsa-188   fail   never pass
 test-xtf-amd64-amd64-2   39 xtf/test-hvm32pse-xsa-188fail   never pass
 test-xtf-amd64-amd64-2 41 xtf/test-hvm64-fpu-exception-emulation fail never 
pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-5   51 xtf/test-hvm64-xsa-188   fail   never pass
 test-xtf-amd64-amd64-2   51 xtf/test-hvm64-xsa-188   fail   never pass
 test-xtf-amd64-amd64-3   19 xtf/test-hvm32-invlpg~hapfail   never pass
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-3   26 xtf/test-hvm32-xsa-188   fail   never pass
 test-xtf-amd64-amd64-3   28 xtf/test-hvm32-xsa-192   fail   never pass
 test-xtf-amd64-amd64-3   35 xtf/test-hvm32pae-xsa-188fail   never pass
 test-xtf-amd64-amd64-3   39 xtf/test-hvm32pse-xsa-188fail   never pass
 test-xtf-amd64-amd64-3 41 xtf/test-hvm64-fpu-exception-emulation fail never 
pass
 test-xtf-amd64-amd64-3   51 xtf/test-hvm64-xsa-188   fail   never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   19 xtf/test-hvm32-invlpg~hapfail   never pass
 test-xtf-amd64-amd64-4   20 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-4   26 xtf/test-hvm32-xsa-188   fail   never pass
 test-xtf-amd64-amd64-4   28 xtf/test-hvm32-xsa-192   fail   never pass
 test-armhf-armhf-xl-midway6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-xtf-amd64-amd64-4   35 xtf/test-hvm32pae-xsa-188fail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-xtf-amd64-amd64-4   39 xtf/test-hvm32pse-xsa-188fail   never pass
 test-xtf-amd64-amd64-4 41 xtf/test-hvm64-fpu-exception-emulation fail never 
pass
 test-xtf-amd64-amd64-4   51 xtf/test-hvm64-xsa-188   fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   53 leak-check/check fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   53 leak-check/check fail   never pass

[Xen-devel] [PATCH] libs/gnttab: add FreeBSD handlers for the grant-table user-space device

2017-01-26 Thread Roger Pau Monne 
This patch adds the headers and helpers for the FreeBSD gntdev, used in order
to map grants from remote domains and to allocate grants on behalf of the
current domain.

Current code has been tested with the QEMU/Qdisk backend.

Signed-off-by: Akshay Jaggi 
[ added dummy stub for osdep_gnttab_grant_copy ]
Signed-off-by: Roger Pau Monné 
---
Cc: Wei Liu 
Cc: Ian Jackson 
---
 tools/include/xen-sys/FreeBSD/gntdev.h | 191 +++
 tools/libs/gnttab/Makefile |   2 +-
 tools/libs/gnttab/freebsd.c| 327 +
 3 files changed, 519 insertions(+), 1 deletion(-)
 create mode 100644 tools/include/xen-sys/FreeBSD/gntdev.h
 create mode 100644 tools/libs/gnttab/freebsd.c

diff --git a/tools/include/xen-sys/FreeBSD/gntdev.h 
b/tools/include/xen-sys/FreeBSD/gntdev.h
new file mode 100644
index 000..f3af9a4
--- /dev/null
+++ b/tools/include/xen-sys/FreeBSD/gntdev.h
@@ -0,0 +1,191 @@
+/*-
+ * Copyright (c) 2016 Akshay Jaggi 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * gntdev.h
+ *
+ * Interface to /dev/xen/gntdev.
+ *
+ * This device provides the user with two kinds of functionalities:
+ * 1. Grant Allocation
+ *Allocate a page of our own memory, and share it with a foreign domain.
+ * 2. Grant Mapping
+ *Map a grant allocated by a foreign domain, into our own memory.
+ *
+ *
+ * Grant Allocation
+ *
+ * Steps to allocate a grant:
+ * 1. Do an `IOCTL_GNTDEV_ALLOC_GREF ioctl`, with
+ * - `domid`, as the domain-id of the foreign domain
+ * - `flags`, ORed with GNTDEV_ALLOC_FLAG_WRITABLE if you want the foreign
+ *   domain to have write access to the shared memory
+ * - `count`, with the number of pages to share with the foreign domain
+ *
+ *Ensure that the structure you allocate has enough memory to store
+ *all the allocated grant-refs, i.e., you need to allocate
+ *(sizeof(struct ioctl_gntdev_alloc_gref) + (count - 1)*sizeof(uint32_t))
+ *bytes of memory.
+ *
+ * 2. Mmap the address given in `index` after a successful ioctl.
+ *This will give you access to the granted pages.
+ *
+ * Note:
+ * 1. The grant is not removed until all three of the following conditions
+ *are met
+ * - The region is not mmaped. That is, munmap() has been called if
+ *   the region was mmapped previously.
+ * - IOCTL_GNTDEV_DEALLOC_GREF ioctl has been performed. After you
+ *   perform this ioctl, you can no longer mmap or set notify on
+ *   the grant.
+ * - The foreign domain has stopped using the grant.
+ * 2. Granted pages can only belong to one mmap region.
+ * 3. Every page of granted memory is a unit in itself. What this means
+ *is that you can set a unmap notification for each of the granted
+ *pages, individually; you can mmap and dealloc-ioctl a contiguous
+ *range of allocated grants (even if alloc-ioctls were performed
+ *individually), etc.
+ *
+ *
+ * Grant Mapping
+ *
+ * Steps to map a grant:
+ * 1. Do a `IOCTL_GNTDEV_MAP_GRANT_REF` ioctl, with
+ * - `count`, as the number of foreign grants to map
+ * - `refs[i].domid`, as the domain id of the foreign domain
+ * - `refs[i].ref`, as the grant-ref for the grant to be mapped
+ *
+ * 2. Mmap the address given in `index` after a successful ioctl.
+ *This will give you access to the mapped pages.
+ *
+ * Note:
+ * 1. The map hypercall is not made till the region is mmapped.
+ * 2. The unit is defined by the map ioctl. This means that only one
+ *unmap notification can be set on a group of pages that were
+ *mapped together

Re: [Xen-devel] Pausing / unpausing a single domain VCPU via libxc

2017-01-26 Thread Dario Faggioli 
[Adding tools people, and Andrew's which, according to git history,
 has touched the involved (Xen) code for last :-) ]

On Thu, 2017-01-26 at 14:08 +0200, Razvan Cojocaru wrote:
> Hello,
> 
> I see that there's currently no xc_vcpu_pause() (there's only
> xc_domain_pause(), which freezes all the VCPUs), but there's
> XEN_DOMCTL_gdbsx_pausevcpu, which is only used by
> tools/debugger/gdbsx/xg/xg_main.c.
> 
> Wouldn't it make sense to have a "regular" DOMCTL in libxc that the
> debugger, as well as other clients, would make use of (said
> xc_vcpu_pause() / xc_vcpu_unpause())?
> 
You mean you'd want to implement xc_vcpu_pause() by means of
the XEN_DOMCTL_gdbsx_pausevcpu?

What's the use case for that, and does it fit with the implementation
of said hypercall (which, e.g., requires that the domain is already
paused)?

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

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

[Xen-devel] [PATCH v2 3/8] hw: Default -drive to if=none instead of ide when ide cannot work

2017-01-26 Thread Markus Armbruster 
Block backends defined with -drive if=ide are meant to be picked up by
machine initialization code: a suitable frontend gets created and
wired up automatically.

if=ide drives not picked up that way can still be used with -device as
if they had if=none, but that's unclean and best avoided.  Unused ones
produce an "Orphaned drive without device" warning.

-drive parameter "if" is optional, and the default depends on the
machine type.  If a machine type doesn't specify a default, the
default is "ide".

Many machine types implicitly default to if=ide that way, even though
they don't actually have an IDE controller.  This makes no sense.

Change the implicit default to if=none.  Affected machines:

* all targets: none
* aarch64/arm: akita ast2500 canon cheetah collie connex imx25
  integratorcp kzm lm3s6965evb lm3s811evb mainstone musicpal n800 n810
  netduino2 nuri palmetto realview romulus sabrelite smdkc210 sx1 sx1
  verdex z2
* cris: axis-dev88
* i386/x86_64: xenpv
* lm32: lm32-evr lm32-uclinux milkymist
* m68k: an5206 dummy mcf5208evb
* microblaze/microblazeel: petalogix-ml605 petalogix-s3adsp1800
* mips/mips64/mips64el/mipsel: mipssim
* moxie: moxiesim
* or32: or32-sim
* ppc/ppc64/ppcemb: bamboo ref405ep taihu virtex-ml507
* ppc/ppc64: mpc8544ds ppce500
* sh4/sh4eb: shix
* sparc: leon3_generic
* sparc64: niagara
* tricore: tricore_testboard
* unicore32: puv3
* xtensa/xtensaeb: kc705 lx200 lx60 ml605 sim

None of these machines have an IDE controller, let alone code to
honor if=ide.

Cc: Peter Maydell 
Cc: qemu-...@nongnu.org
Cc: Edgar E. Iglesias 
Cc: Stefano Stabellini 
Cc: Anthony Perard 
Cc: xen-de...@lists.xensource.com
Cc: Michael Walle 
Cc: Laurent Vivier 
Cc: Anthony Green 
Cc: Jia Liu 
Cc: Alexander Graf 
Cc: qemu-...@nongnu.org
Cc: Magnus Damm 
Cc: Fabien Chouteau 
Cc: Mark Cave-Ayland 
Cc: Artyom Tarasenko 
Cc: Bastian Koppelmann 
Cc: Guan Xuetao 
Cc: Max Filippov 
Signed-off-by: Markus Armbruster 
Acked-By: Artyom Tarasenko 
---
 include/sysemu/blockdev.h | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/include/sysemu/blockdev.h b/include/sysemu/blockdev.h
index 16432f3..351a039 100644
--- a/include/sysemu/blockdev.h
+++ b/include/sysemu/blockdev.h
@@ -19,12 +19,11 @@ void blockdev_auto_del(BlockBackend *blk);
 typedef enum {
 IF_DEFAULT = -1,/* for use with drive_add() only */
 /*
- * IF_IDE must be zero, because we want MachineClass member
- * block_default_type to default-initialize to IF_IDE
+ * IF_NONE must be zero, because we want MachineClass member
+ * block_default_type to default-initialize to IF_NONE
  */
-IF_IDE = 0,
-IF_NONE,
-IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
+IF_NONE = 0,
+IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
 IF_COUNT
 } BlockInterfaceType;
 
-- 
2.7.4


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

Re: [Xen-devel] [linux-linus test] 104684: regressions - FAIL

2017-01-26 Thread Boris Ostrovsky 
On 01/26/2017 08:23 AM, osstest service owner wrote:
> flight 104684 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/104684/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 
> 59254
>  test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 
> 59254
>  test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 
> 59254
>  test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 
> 59254
>  test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 
> 59254

I don't see why AMR tests fail. But then I also don't see (in the serial
log) the output of 4.10.0-rc5 being booted. There is U-Boot loading it
but there it nothing coming to the console from it.

There is output from 3.16 kernels though.

>  test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail REGR. 
> vs. 59254

This one fails in xc_domain_populate_physmap_exact during restore:
xc: detail: Failed allocation for dom 4: 1024 extents of order 0


-boris


>  test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 
> 59254



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

[Xen-devel] [PATCH v3] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

2017-01-26 Thread David Woodhouse 
From: David Woodhouse 

For some MMIO regions, such as those high above RAM, mfn_valid() will
return false.

Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce
consistent cachability of MMIO mappings"), guests have no longer been
able to use PAT to obtain write-combining on such regions because the
'ignore PAT' bit is set in EPT.

We probably want to err on the side of caution and preserve that
behaviour for addresses in mmio_ro_ranges, but not for normal MMIO
mappings. That necessitates a slight refactoring to check mfn_valid()
later, and let the MMIO case get through to the right code path.

Since we're not bailing out for !mfn_valid() immediately, the range
checks need to be adjusted to cope — simply by masking in the low bits
to account for 'order' instead of adding, to avoid overflow when the mfn
is INVALID_MFN (which happens on unmap, since we carefully call this
function to fill in the EMT even though the PTE won't be valid).

The range checks are also slightly refactored to put only one of them in
the fast path in the common case. If it doesn't overlap, then it
*definitely* isn't contained, so we don't need both checks. And if it
overlaps and is only one page, then it definitely *is* contained.

Finally, add a comment clarifying how that 'return -1' works — it isn't
returning an error and causing the mapping to fail; it relies on
resolve_misconfig() being able to split the mapping later. So it's
*only* sane to do it where order>0 and the 'problem' will be solved by
splitting the large page. Not for blindly returning 'error', which I was
tempted to do in my first attempt.

Signed-off-by: David Woodhouse 
---
 xen/arch/x86/hvm/mtrr.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 709759c..8fef756 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -773,17 +773,19 @@ int epte_get_entry_emt(struct domain *d, unsigned long 
gfn, mfn_t mfn,
 if ( v->domain != d )
 v = d->vcpu ? d->vcpu[0] : NULL;
 
-if ( !mfn_valid(mfn_x(mfn)) ||
- rangeset_contains_range(mmio_ro_ranges, mfn_x(mfn),
- mfn_x(mfn) + (1UL << order) - 1) )
-{
-*ipat = 1;
-return MTRR_TYPE_UNCACHABLE;
-}
-
+/* Mask, not add, for order so it works with INVALID_MFN on unmapping */
 if ( rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
- mfn_x(mfn) + (1UL << order) - 1) )
+ mfn_x(mfn) | ((1UL << order) - 1)) )
+{
+if ( !order || rangeset_contains_range(mmio_ro_ranges, mfn_x(mfn),
+   mfn_x(mfn) | ((1UL << order) - 
1)) )
+{
+*ipat = 1;
+return MTRR_TYPE_UNCACHABLE;
+}
+/* Force invalid memory type so resolve_misconfig() will split it */
 return -1;
+}
 
 if ( direct_mmio )
 {
@@ -795,6 +797,12 @@ int epte_get_entry_emt(struct domain *d, unsigned long 
gfn, mfn_t mfn,
 return MTRR_TYPE_WRBACK;
 }
 
+if ( !mfn_valid(mfn_x(mfn)) )
+{
+*ipat = 1;
+return MTRR_TYPE_UNCACHABLE;
+}
+
 if ( !need_iommu(d) && !cache_flush_permitted(d) )
 {
 *ipat = 1;
-- 
2.7.4


smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

2017-01-26 Thread David Woodhouse 
On Thu, 2017-01-26 at 07:35 -0700, Jan Beulich wrote:
> 
> Hmm, didn't you say you'd take care of the hard tabs?

Er... yes. But it seems I neglected to specify whether I would also
*save* the resulting file, 'git commit --amend', and actually send that
version. Sorry.

smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/ept: Allow write-combining on !mfn_valid() MMIO mappings again

2017-01-26 Thread Jan Beulich 
>>> On 26.01.17 at 13:39,  wrote:
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -773,18 +773,20 @@ int epte_get_entry_emt(struct domain *d, unsigned long 
> gfn, mfn_t mfn,
>  if ( v->domain != d )
>  v = d->vcpu ? d->vcpu[0] : NULL;
>  
> -if ( !mfn_valid(mfn_x(mfn)) ||
> - rangeset_contains_range(mmio_ro_ranges, mfn_x(mfn),
> - mfn_x(mfn) + (1UL << order) - 1) )
> +/* Mask, not add, for order so it works with INVALID_MFN on unmapping */
> +if ( rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
> +  mfn_x(mfn) | ((1UL << order) - 1)) )

Hmm, didn't you say you'd take care of the hard tabs?

Jan


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

[Xen-devel] POSIX error names and codes in PV protocols

2017-01-26 Thread Oleksandr Andrushchenko 

Hi, all!

There is some work happening on new PV protocols: sndif [1],

displif [2], PV calls [3] and the common part of those is that

error/status codes must be returned as a part of a response packet.

For that Konrad suggested [1] (and Stefano already used in [3]) POSIX

to be employed here instead of defining protocol specific error codes.

The problem I see here is that POSIX only defines names of the errors,

but not values [4]. So, in order to use POSIX one still needs to define

the values (names must be the same, but values may differ for different 
OSes).


So, the question is what would be the best option to

a) have those numbers defined in OS agnostic way

b) have those defined for all PV protocols

Stefano has already defined the error code values in his work [3],

but for other protocols this should be reimplemented again.


Thank you,

Oleksandr

[1] https://marc.info/?l=xen-devel=148528530727366=2

[2] https://marc.info/?l=xen-devel=148239440624498=2

[3] https://marc.info/?l=xen-devel=148530334732400=2

[4] http://pubs.opengroup.org/onlinepubs/007908799/xsh/errno.h.html


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

Re: [Xen-devel] [PATCH 5/7] fuzz/x86emul: update fuzzer

2017-01-26 Thread Jan Beulich 
>>> On 26.01.17 at 13:02,  wrote:
> On 26/01/17 11:28, Jan Beulich wrote:
> On 25.01.17 at 16:44,  wrote:
>>> --- a/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
>>> +++ b/tools/fuzz/x86_instruction_emulator/x86-insn-emulator-fuzzer.c
>>> @@ -16,26 +16,75 @@
>>>  
>>>  #include "x86_emulate.h"
>>>  
>>> -static unsigned char data[4096];
>>> +#include "../../../xen/include/asm-x86/msr-index.h"
>>> +
>>> +#ifndef offsetof
>>> +#define offsetof(t,m) ((size_t)&(((t *)0)->m))
>>> +#endif
>> 
>> Why can't you include the standard header for this?
> 
> [Responding because this is code I wrote]
> 
> Because I didn't know where it was.  What's the best thing to include to
> get this?

The standard says stddef.h.

>>> +return X86EMUL_EXCEPTION;
>>> +else
>>> +{
>>> +if ( input.data[data_index] > 0xc )
>>> +rc = X86EMUL_EXCEPTION;
>>> +else if ( input.data[data_index] > 0x8 )
>>> +rc = X86EMUL_UNHANDLEABLE;
>> 
>> How were these numbers chosen?
> 
> The idea here is to give the fuzzer a way of (blindly) changing whether
> the operation succeeds or how it fails in a "modular" way, by just
> "consuming" one byte from the input.  The numbers are meant to make
> random values roughly 50% succeed, 25% generate an exception, and 25%
> return unhandleable.

But the vast majority of cases would fall in the exception group. Did
you perhaps mean 0xc0 and 0x80 then? In any event a comment
would be nice to clarify the intention.

>>> +static int fuzz_cpuid(
>>> +uint32_t leaf,
>>> +uint32_t subleaf,
>>> +struct cpuid_leaf *res,
>>> +struct x86_emulate_ctxt *ctxt)
>>> +{
>>> +int rc;
>>> +
>>> +rc = maybe_fail("cpuid", true);
>>> +
>>> +if ( rc == X86EMUL_OKAY )
>>> +emul_test_cpuid(leaf, subleaf, res, ctxt);
>>> +
>>> +return rc;
>>> +}
>> 
>> Careful here: ->cpuid() is documented to only be allowed to fail with
>> X86EMUL_EXCEPTION.
> 
> But at the moment, the emulator seems to function properly even if you
> return UNHANDLEABLE.  This is probably more robust than otherwise.

Hmm, yes and no. Considering it being documented that way,
someone adding an ASSERT() to that effect would be a legitimate
thing to do, yet would result in aborts for suitable input here.

>>> +static void setup_fpu_exception_handler(void)
>>> +{
>>> +/* FIXME - just disable exceptions for now */
>>> +unsigned long a;
>>> +
>>> +asm volatile ( "fnclex");
>>> +a=0x3f;
>>> +asm volatile ( "fldcw %0" :: "m" (a));
>>> +a=0x1f80;
>>> +asm volatile ( "ldmxcsr %0" :: "m" (a) );
>> 
>> I don't see what you need "a" for in this function. And I also wonder
>> how the FCW value was chosen (the MXCSR one is a commonly used
>> value).
> 
> I just copied it from somewhere.  Could you suggest something better?

The FCW_DEFAULT (0x037f) value from the hypervisor.

>>> +/*
>>> + * Constrain input to architecturally-possible states where
>>> + * the emulator relies on these
>>> + *
>>> + * In general we want the emulator to be as absolutely robust as
>>> + * possible; which means that we want to minimize the number of things
>>> + * it assumes about the input state.  Tesing this means minimizing and
>>> + * removing as much of the input constraints as possible.
>>> + *
>>> + * So we only add constraints that (in general) have been proven to
>>> + * cause crashes in the emulator.
>>> + *
>>> + * For future reference: other constraints which might be necessary at
>>> + * some point:
>>> + *
>>> + * - EFER.LMA => !EFLAGS.NT
>>> + * - In VM86 mode (and real mode?), force segment...
>> 
>> As per commit 05118b1596 real mode should not be included here.
>> 
>>> + *  - ...access rights to 0xf3
>>> + *  - ...limits to 0x
>>> + *  - ...bases to below 1Mb, 16-byte aligned
>>> + *  - ...selectors to (base >> 4)
>> 
>> Most of this does not match the implementation (which only clear
>> DB for CS and SS).
> 
> You mean that the code here doesn't actually do this?  Yes, that's what
> the comment says -- "For future reference, other constraints which may
> be necessary at some point" -- that is, restrictions which exist in the
> architecture but do not (yet) exist in this code.

Oh, yes, I'm sorry. When coming back up here from below (where
the respective code is) I didn't go back far enough in the comment
to note the "For future reference:".

>>> + */
>>> +void sanitize_input(struct x86_emulate_ctxt *ctxt) {
>>> +struct cpu_user_regs *regs = 
>>> +unsigned long bitmap = input.options;
>>> +
>>> +input.options &=
>>> +~((1<>> +  (1<>> +  (1<>> +  (1<> 
>> Ah, this addresses one of the earlier remarks. However, ->write
>> and ->cmpxchg have become optional a little while ago.
> 
> And yet, empirically, the emulator crashes if you don't have them.  If
> this isn't expected, we should

Re: [Xen-devel] [PATCH v5 9/9] xen/x86: setup PVHv2 Dom0 ACPI tables

2017-01-26 Thread Jan Beulich 
>>> On 19.01.17 at 18:29,  wrote:
> +static int __init pvh_setup_acpi_madt(struct domain *d, paddr_t *addr)
> +{
> +struct acpi_table_madt *madt;
> +struct acpi_table_header *table;
> +struct acpi_madt_io_apic *io_apic;
> +struct acpi_madt_local_apic *local_apic;
> +struct acpi_madt_local_x2apic *x2apic;
> +acpi_status status;
> +unsigned long size;
> +unsigned int i, max_vcpus;
> +int rc;
> +
> +/* Count number of interrupt overrides in the MADT. */
> +acpi_table_parse_madt(ACPI_MADT_TYPE_INTERRUPT_OVERRIDE,
> +  acpi_count_intr_ovr, UINT_MAX);
> +
> +/* Count number of NMI sources in the MADT. */
> +acpi_table_parse_madt(ACPI_MADT_TYPE_NMI_SOURCE, acpi_count_nmi_src,
> +  UINT_MAX);
> +
> +/* Check if there are x2APIC entries. */
> +acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC, acpi_check_x2apic, 1);
> +
> +max_vcpus = dom0_max_vcpus();
> +/* Calculate the size of the crafted MADT. */
> +size = sizeof(*madt);
> +size += sizeof(*io_apic);

Still just a single IO-APIC and no fixme note. I see you have one
below, but this line will need to remain in lock step. Or perhaps you
could multiply by nr_ioapics here, accepting the transient waste of
space.

> +/*
> + * The APIC ID field of the local APIC struct is only 1byte, so we need
> + * to limit the number of local APIC entries to 128 because we only use
> + * even numbers as APIC IDs.
> + */
> +size += sizeof(*local_apic) *
> +min(max_vcpus, 1U << (sizeof(local_apic->id) * 8));

This caps at 256 now. Perhaps it would anyway be better to use
HVM_MAX_VCPUS here, or maybe the minimum of both?

> +size += sizeof(*intsrcovr) * acpi_intr_overrides;
> +size += sizeof(*nmisrc) * acpi_nmi_sources;
> +size += acpi_x2apic ? sizeof(*x2apic) * dom0_max_vcpus() : 0;

You have the function call result already latched in a local variable.
Plus, when you cap LAPIC entries, you should also provide x2APIC
ones (to be able to represent all vCPU-s).

> +madt = xzalloc_bytes(size);
> +if ( !madt )
> +{
> +printk("Unable to allocate memory for MADT table\n");
> +return -ENOMEM;
> +}
> +
> +/* Copy the native MADT table header. */
> +status = acpi_get_table(ACPI_SIG_MADT, 0, );
> +if ( !ACPI_SUCCESS(status) )
> +{
> +printk("Failed to get MADT ACPI table, aborting.\n");
> +return -EINVAL;
> +}
> +madt->header = *table;
> +madt->address = APIC_DEFAULT_PHYS_BASE;
> +/*
> + * NB: this is currently set to 4, which is the revision in the ACPI
> + * spec 6.1. Sadly ACPICA doesn't provide revision numbers for the
> + * tables described in the headers.
> + */
> +madt->header.revision = min_t(unsigned char, table->revision, 4);
> +
> +/*
> + * Setup the IO APIC entry.
> + * FIXME: the current vIO-APIC code just supports one IO-APIC instance
> + * per domain. This must be fixed in order to provide the same amount of
> + * IO APICs as available on bare metal, and with the same IDs as found in
> + * the native IO APIC MADT entries.
> + */
> +if ( nr_ioapics > 1 )
> +printk("WARNING: found %d IO APICs, Dom0 will only have access to 1 
> emulated IO APIC\n",
> +   nr_ioapics);
> +io_apic = (struct acpi_madt_io_apic *)(madt + 1);

To aid readability you may want to use void in all such casts.

> +static bool __init pvh_acpi_table_allowed(const char *sig)
> +{
> +static const char __init banned_tables[][ACPI_NAME_SIZE] = {

__initconst

> +ACPI_SIG_HPET, ACPI_SIG_SLIT, ACPI_SIG_SRAT, ACPI_SIG_MPST,
> +ACPI_SIG_PMTT, ACPI_SIG_MADT, ACPI_SIG_DMAR};
> +int i;

unsigned int

> +static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr,
> +  paddr_t *addr)
> +{
> +struct acpi_table_xsdt *xsdt;
> +struct acpi_table_header *table;
> +struct acpi_table_rsdp *rsdp;
> +unsigned long size = sizeof(*xsdt);
> +unsigned int i, j, num_tables = 0;
> +paddr_t xsdt_paddr;
> +int rc;
> +
> +/*
> + * Restore original DMAR table signature, we are going to filter it
> + * from the new XSDT that is presented to the guest, so it no longer
> + * makes sense to have it's signature zapped.

"... so it is no longer necessary to ..."?

> +static int __init pvh_setup_acpi(struct domain *d, paddr_t start_info)
> +{
> +struct acpi_table_rsdp rsdp, *native_rsdp;
> +unsigned long pfn, nr_pages;
> +paddr_t madt_paddr, xsdt_paddr, rsdp_paddr;
> +unsigned int i;
> +int rc;
> +
> +/* Scan top-level tables and add their regions to the guest memory map. 
> */
> +for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> +{
> +const char *sig = acpi_gbl_root_table_list.tables[i].signature.ascii;
> +unsigned long addr =

[Xen-devel] [xen-unstable-smoke test] 104709: regressions - trouble: blocked/broken/fail

2017-01-26 Thread osstest service owner 
flight 104709 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104709/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-buildfail REGR. vs. 104630
 build-armhf   5 xen-buildfail REGR. vs. 104630

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  91f59d2041b0f2760da082827bcea57648845cc1
baseline version:
 xen  c13f0f9a331153a57eedfe8c80f1e2f6d4f01dcc

Last test of basis   104630  2017-01-24 19:01:56 Z1 days
Failing since104642  2017-01-25 10:01:54 Z1 days   26 attempts
Testing same since   104648  2017-01-25 15:01:38 Z0 days   23 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Dario Faggioli 
  Elena Ufimtseva 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Praveen Kumar 
  Roger Pau Monné 
  Tim Deegan 
  Venu Busireddy 
  Wei Liu 

jobs:
 build-amd64  fail
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  blocked 
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt 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.

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

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

Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce __HYPERCALL_dm_op...

2017-01-26 Thread Boris Ostrovsky 
On 01/26/2017 08:55 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>> Sent: 26 January 2017 13:26
>> To: Paul Durrant ; xen-de...@lists.xenproject.org
>> Cc: Ian Jackson ; Jennifer Herbert
>> ; Jan Beulich 
>> Subject: Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce
>> __HYPERCALL_dm_op...
>>
>> On 01/24/2017 10:27 AM, Paul Durrant wrote:
>>> ...as a set of hypercalls to be used by a device model.
>>>
>>> As stated in the new docs/designs/dm_op.markdown:
>>>
>>> "The aim of DMOP is to prevent a compromised device model from
>>> compromising domains other then the one it is associated with. (And is
>>> therefore likely already compromised)."
>>>
>>> See that file for further information.
>>>
>>> This patch simply adds the boilerplate for the hypercall.
>>>
>>> Signed-off-by: Paul Durrant 
>>> Suggested-by: Ian Jackson 
>>> Suggested-by: Jennifer Herbert 
>>> Acked-by: Daniel De Graaf 
>>> Acked-by: Wei Liu 
>>> Reviewed-by: Andrew Cooper 
>> This patch (and possibly others in the series) break FLASK-enabled build.
> Boris,
>
>   See the thread starting at 
> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg02721.html
>
>   I believe Wei still awaiting an ack.


Ah, I missed that. Sorry about that.

-boris

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

Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce __HYPERCALL_dm_op...

2017-01-26 Thread Paul Durrant 
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 26 January 2017 13:26
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Jennifer Herbert
> ; Jan Beulich 
> Subject: Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce
> __HYPERCALL_dm_op...
> 
> On 01/24/2017 10:27 AM, Paul Durrant wrote:
> > ...as a set of hypercalls to be used by a device model.
> >
> > As stated in the new docs/designs/dm_op.markdown:
> >
> > "The aim of DMOP is to prevent a compromised device model from
> > compromising domains other then the one it is associated with. (And is
> > therefore likely already compromised)."
> >
> > See that file for further information.
> >
> > This patch simply adds the boilerplate for the hypercall.
> >
> > Signed-off-by: Paul Durrant 
> > Suggested-by: Ian Jackson 
> > Suggested-by: Jennifer Herbert 
> > Acked-by: Daniel De Graaf 
> > Acked-by: Wei Liu 
> > Reviewed-by: Andrew Cooper 
> 
> This patch (and possibly others in the series) break FLASK-enabled build.

Boris,

  See the thread starting at 
https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg02721.html

  I believe Wei still awaiting an ack.

Paul

> 
> First, this
> 
> > diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> > index 95460af..b206f5a 100644
> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -727,6 +727,12 @@ static XSM_INLINE int xsm_pmu_op
> (XSM_DEFAULT_ARG struct domain *d, unsigned int
> >  }
> >  }
> >
> > +static XSM_INLINE int xsm_dm_op(XSM_DEFAULT_ARG struct domain
> *d)
> > +{
> > +XSM_ASSERT_ACTION(XSM_DM_PRIV);
> > +return xsm_default_action(action, current->domain, d);
> > +}
> > +
> >
> 
> generates
> 
> /home/build/xtt-x86_64/bootstrap/xen.git/xen/include/xsm/dummy.h:700:
> error: ‘xsm_dm_op’ defined but not used
> 
> and I think needs
> 
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index 1f659c7..3cb5492 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -156,6 +156,7 @@ void __init xsm_fixup_ops (struct xsm_operations
> *ops)
>  set_to_dummy_if_null(ops, ioport_permission);
>  set_to_dummy_if_null(ops, ioport_mapping);
>  set_to_dummy_if_null(ops, pmu_op);
> +set_to_dummy_if_null(ops, dm_op);
>  #endif
>  set_to_dummy_if_null(ops, xen_version);
>  }
> 
> 
> And then
> 
> make[4]: Entering directory
> `/home/build/xtt-x86_64/bootstrap/xen.git/xen/xsm/flask'
> gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall
> -Wstrict-prototypes -Wdeclaration-after-statement
> -Wno-unused-but-set-variable   -O1 -nostdinc -fno-builtin -fno-common
> -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include
> /home/build/xtt-x86_64/bootstrap/xen.git/xen/include/xen/config.h
> '-D__OBJECT_FILE__="hooks.o"' -Wa,--strip-local-absolute
> -fno-omit-frame-pointer -MMD -MF ./.hooks.o.d
> -I/home/build/xtt-x86_64/bootstrap/xen.git/xen/include
> -I/home/build/xtt-x86_64/bootstrap/xen.git/xen/include/asm-x86/mach-
> generic
> -I/home/build/xtt-x86_64/bootstrap/xen.git/xen/include/asm-x86/mach-
> default
> '-D__OBJECT_LABEL__=xsm$flask$hooks.o' -msoft-float -fno-stack-protector
> -fno-exceptions -Wnested-externs -DHAVE_GAS_VMX -
> DHAVE_GAS_SSE4_2
> -DHAVE_GAS_EPT -mno-red-zone -mno-sse -fpic
> -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE
> -I./include -c hooks.c -o hooks.o
> hooks.c: In function ‘flask_dm_op’:
> hooks.c:1613: error: ‘HVM__DM’ undeclared (first use in this function)
> hooks.c:1613: error: (Each undeclared identifier is reported only once
> hooks.c:1613: error: for each function it appears in.)
> hooks.c: At top level:
> hooks.c:1779: error: unknown field ‘hvm_set_pci_intx_level’ specified in
> initializer
> hooks.c:1779: error: ‘flask_hvm_set_pci_intx_level’ undeclared here (not
> in a function)
> hooks.c:1780: error: unknown field ‘hvm_set_isa_irq_level’ specified in
> initializer
> hooks.c:1780: error: ‘flask_hvm_set_isa_irq_level’ undeclared here (not
> in a function)
> hooks.c:1781: error: unknown field ‘hvm_set_pci_link_route’ specified in
> initializer
> hooks.c:1781: error: ‘flask_hvm_set_pci_link_route’ undeclared here (not
> in a function)
> make[4]: *** [hooks.o] Error 1
> 
> 
> -boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 8/9] xen/x86: Setup PVHv2 Dom0 CPUs

2017-01-26 Thread Jan Beulich 
>>> On 19.01.17 at 18:29,  wrote:
> @@ -2096,6 +2097,56 @@ static int __init pvh_load_kernel(struct domain *d, 
> const module_t *image,
>  return 0;
>  }
>  
> +static int __init pvh_setup_cpus(struct domain *d, paddr_t entry,
> + paddr_t start_info)
> +{
> +vcpu_hvm_context_t cpu_ctx;
> +struct vcpu *v = d->vcpu[0];
> +int cpu, i, rc;

i and cpu want to be unsigned int.

> +cpu = v->processor;
> +for ( i = 1; i < d->max_vcpus; i++ )
> +{
> +cpu = cpumask_cycle(cpu, _cpus);
> +setup_dom0_vcpu(d, i, cpu);
> +}
> +
> +memset(_ctx, 0, sizeof(cpu_ctx));

Perhaps better (and shorter) to use an initializer again?

> +cpu_ctx.mode = VCPU_HVM_MODE_32B;
> +
> +cpu_ctx.cpu_regs.x86_32.ebx = start_info;
> +cpu_ctx.cpu_regs.x86_32.eip = entry;
> +cpu_ctx.cpu_regs.x86_32.cr0 = X86_CR0_PE | X86_CR0_ET;
> +
> +cpu_ctx.cpu_regs.x86_32.cs_limit = ~0u;
> +cpu_ctx.cpu_regs.x86_32.ds_limit = ~0u;
> +cpu_ctx.cpu_regs.x86_32.ss_limit = ~0u;
> +cpu_ctx.cpu_regs.x86_32.tr_limit = 0x67;
> +cpu_ctx.cpu_regs.x86_32.cs_ar = 0xc9b;
> +cpu_ctx.cpu_regs.x86_32.ds_ar = 0xc93;
> +cpu_ctx.cpu_regs.x86_32.ss_ar = 0xc93;
> +cpu_ctx.cpu_regs.x86_32.tr_ar = 0x8b;

In fact, all of this could become part of the initializer too as it looks.

> @@ -2124,6 +2175,15 @@ static int __init construct_dom0_pvh(struct domain *d, 
> const module_t *image,
>  return rc;
>  }
>  
> +rc = pvh_setup_cpus(d, entry, start_info);
> +if ( rc )
> +{
> +printk("Failed to setup Dom0 CPUs: %d\n", rc);
> +return rc;
> +}
> +
> +clear_bit(_VPF_down, >vcpu[0]->pause_flags);

Would you mind moving this into the function (where you then can
use just v)?

Jan


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

Re: [Xen-devel] [PATCH v5 7/9] x86/PVHv2: fix dom0_max_vcpus so it's capped to 128 for PVHv2 Dom0

2017-01-26 Thread Jan Beulich 
>>> On 19.01.17 at 18:29,  wrote:
> @@ -176,6 +177,8 @@ unsigned int __init dom0_max_vcpus(void)
>  max_vcpus = opt_dom0_max_vcpus_max;
>  if ( max_vcpus > MAX_VIRT_CPUS )
>  max_vcpus = MAX_VIRT_CPUS;
> +if ( dom0_pvh && max_vcpus > HVM_MAX_VCPUS )
> +max_vcpus = HVM_MAX_VCPUS;

Thinking about it again, we shouldn't apply two limits here, when
those limits can change independently. I think you want

limit = dom0_pvh ? HVM_MAX_VCPUS : MAX_VIRT_CPUS;
if ( max_vcpus > limit )
 max_vcpus = limit;

Jan


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

Re: [Xen-devel] [PATCH v5 6/9] xen/x86: parse Dom0 kernel for PVHv2

2017-01-26 Thread Jan Beulich 
>>> On 19.01.17 at 18:29,  wrote:
> @@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d)
>  #undef MB1_PAGES
>  }
>  
> +static int __init pvh_load_kernel(struct domain *d, const module_t *image,
> +  unsigned long image_headroom,
> +  module_t *initrd, char *image_base,
> +  char *cmdline, paddr_t *entry,
> +  paddr_t *start_info_addr)
> +{
> +char *image_start = image_base + image_headroom;

While for cmdline plain char is certainly fine, I think we should stop
abusing this type for image and image_base, even if this means
some further adjustments elsewhere. This really ought to be u8 or
unsigned char.

> +unsigned long image_len = image->mod_end;
> +struct elf_binary elf;
> +struct elf_dom_parms parms;
> +paddr_t last_addr;
> +struct hvm_start_info start_info;
> +struct hvm_modlist_entry mod = { 0 };
> +struct vcpu *saved_current, *v = d->vcpu[0];
> +int rc;
> +
> +if ( (rc = bzimage_parse(image_base, _start, _len)) != 0 )
> +{
> +printk("Error trying to detect bz compressed kernel\n");
> +return rc;
> +}
> +
> +if ( (rc = elf_init(, image_start, image_len)) != 0 )
> +{
> +printk("Unable to init ELF\n");
> +return rc;
> +}
> +#ifdef VERBOSE
> +elf_set_verbose();
> +#endif
> +elf_parse_binary();
> +if ( (rc = elf_xen_parse(, )) != 0 )
> +{
> +printk("Unable to parse kernel for ELFNOTES\n");
> +return rc;
> +}
> +
> +if ( parms.phys_entry == UNSET_ADDR32 ) {

Please move the brace to its own line.

> +printk("Unable to find XEN_ELFNOTE_PHYS32_ENTRY address\n");
> +return -EINVAL;
> +}
> +
> +printk("OS: %s version: %s loader: %s bitness: %s\n", parms.guest_os,
> +   parms.guest_ver, parms.loader,
> +   elf_64bit() ? "64-bit" : "32-bit");
> +
> +/* Copy the OS image and free temporary buffer. */
> +elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
> +elf.dest_size = parms.virt_kend - parms.virt_kstart;
> +
> +/*
> + * NB: we need to set vCPU 0 of Dom0 as the current vCPU (instead of the
> + * idle one) because elf_load_binary calls raw_{copy_to/clear}_guest, and
> + * the target domain is not passed anywhere. This is very similar to what
> + * is done during classic PV Dom0 creation, where Xen switches to the 
> Dom0
> + * page tables. We also cannot pass a struct domain or vcpu to
> + * elf_load_binary, since the interface is shared with the toolstack, and
> + * it doesn't have any notion of a domain or vcpu struct.
> + */
> +saved_current = current;
> +set_current(v);
> +rc = elf_load_binary();
> +set_current(saved_current);

While with the comment it's not as bad anymore, I'm still not happy
with this code. The tool stack portion of the explanation in particular
does not really hold: We would add an opaque void * parameter to
the functions involved, which the tool stack could pass NULL for, and
you'd use it to convey the vcpu.

> +if ( rc < 0 )
> +{
> +printk("Failed to load kernel: %d\n", rc);
> +printk("Xen dom0 kernel broken ELF: %s\n", elf_check_broken());
> +return rc;
> +}
> +
> +last_addr = ROUNDUP(parms.virt_kend - parms.virt_base, PAGE_SIZE);
> +
> +if ( initrd != NULL )
> +{
> +rc = hvm_copy_to_guest_phys_vcpu(last_addr,
> + mfn_to_virt(initrd->mod_start),
> + initrd->mod_end, v);
> +if ( rc )
> +{
> +printk("Unable to copy initrd to guest\n");
> +return rc;
> +}
> +
> +mod.paddr = last_addr;
> +mod.size = initrd->mod_end;
> +last_addr += ROUNDUP(initrd->mod_end, PAGE_SIZE);
> +}
> +
> +/* Free temporary buffers. */
> +discard_initial_images();
> +
> +memset(_info, 0, sizeof(start_info));

You clear "mod" with an initializer (which btw could be just the two
braces), but you memset() start_info - please be consistent.

> +if ( cmdline != NULL )
> +{
> +rc = hvm_copy_to_guest_phys_vcpu(last_addr, cmdline,
> + strlen(cmdline) + 1, v);
> +if ( rc )
> +{
> +printk("Unable to copy guest command line\n");
> +return rc;
> +}
> +start_info.cmdline_paddr = last_addr;
> +last_addr += ROUNDUP(strlen(cmdline) + 1, 8);

Where is this 8 coming from?

Jan

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

Re: [Xen-devel] [PATCH v5 5/9] x86/hvm: add vcpu parameter to guest memory copy function

2017-01-26 Thread Jan Beulich 
>>> On 19.01.17 at 18:29,  wrote:
> --- a/xen/include/asm-x86/hvm/support.h
> +++ b/xen/include/asm-x86/hvm/support.h
> @@ -71,6 +71,8 @@ enum hvm_copy_result hvm_copy_to_guest_phys(
>  paddr_t paddr, void *buf, int size);
>  enum hvm_copy_result hvm_copy_from_guest_phys(
>  void *buf, paddr_t paddr, int size);
> +enum hvm_copy_result hvm_copy_to_guest_phys_vcpu(
> +paddr_t paddr, void *buf, size_t size, struct vcpu *vcpu);

Btw., there being just five existing callers, I think we should rather
change the existing function instead of adding yet another wrapper
of __hvm_copy().

Jan


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

Re: [Xen-devel] [PATCH v8 1/8] public / x86: Introduce __HYPERCALL_dm_op...

2017-01-26 Thread Boris Ostrovsky 
On 01/24/2017 10:27 AM, Paul Durrant wrote:
> ...as a set of hypercalls to be used by a device model.
>
> As stated in the new docs/designs/dm_op.markdown:
>
> "The aim of DMOP is to prevent a compromised device model from
> compromising domains other then the one it is associated with. (And is
> therefore likely already compromised)."
>
> See that file for further information.
>
> This patch simply adds the boilerplate for the hypercall.
>
> Signed-off-by: Paul Durrant 
> Suggested-by: Ian Jackson 
> Suggested-by: Jennifer Herbert 
> Acked-by: Daniel De Graaf 
> Acked-by: Wei Liu 
> Reviewed-by: Andrew Cooper 

This patch (and possibly others in the series) break FLASK-enabled build.

First, this

> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index 95460af..b206f5a 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -727,6 +727,12 @@ static XSM_INLINE int xsm_pmu_op (XSM_DEFAULT_ARG struct 
> domain *d, unsigned int
>  }
>  }
>  
> +static XSM_INLINE int xsm_dm_op(XSM_DEFAULT_ARG struct domain *d)
> +{
> +XSM_ASSERT_ACTION(XSM_DM_PRIV);
> +return xsm_default_action(action, current->domain, d);
> +}
> +
>

generates

/home/build/xtt-x86_64/bootstrap/xen.git/xen/include/xsm/dummy.h:700:
error: ‘xsm_dm_op’ defined but not used

and I think needs

diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 1f659c7..3cb5492 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -156,6 +156,7 @@ void __init xsm_fixup_ops (struct xsm_operations *ops)
 set_to_dummy_if_null(ops, ioport_permission);
 set_to_dummy_if_null(ops, ioport_mapping);
 set_to_dummy_if_null(ops, pmu_op);
+set_to_dummy_if_null(ops, dm_op);
 #endif
 set_to_dummy_if_null(ops, xen_version);
 }


And then

make[4]: Entering directory
`/home/build/xtt-x86_64/bootstrap/xen.git/xen/xsm/flask'
gcc -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable   -O1 -nostdinc -fno-builtin -fno-common
-Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include
/home/build/xtt-x86_64/bootstrap/xen.git/xen/include/xen/config.h
'-D__OBJECT_FILE__="hooks.o"' -Wa,--strip-local-absolute
-fno-omit-frame-pointer -MMD -MF ./.hooks.o.d
-I/home/build/xtt-x86_64/bootstrap/xen.git/xen/include
-I/home/build/xtt-x86_64/bootstrap/xen.git/xen/include/asm-x86/mach-generic
-I/home/build/xtt-x86_64/bootstrap/xen.git/xen/include/asm-x86/mach-default
'-D__OBJECT_LABEL__=xsm$flask$hooks.o' -msoft-float -fno-stack-protector
-fno-exceptions -Wnested-externs -DHAVE_GAS_VMX -DHAVE_GAS_SSE4_2
-DHAVE_GAS_EPT -mno-red-zone -mno-sse -fpic
-fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE
-I./include -c hooks.c -o hooks.o
hooks.c: In function ‘flask_dm_op’:
hooks.c:1613: error: ‘HVM__DM’ undeclared (first use in this function)
hooks.c:1613: error: (Each undeclared identifier is reported only once
hooks.c:1613: error: for each function it appears in.)
hooks.c: At top level:
hooks.c:1779: error: unknown field ‘hvm_set_pci_intx_level’ specified in
initializer
hooks.c:1779: error: ‘flask_hvm_set_pci_intx_level’ undeclared here (not
in a function)
hooks.c:1780: error: unknown field ‘hvm_set_isa_irq_level’ specified in
initializer
hooks.c:1780: error: ‘flask_hvm_set_isa_irq_level’ undeclared here (not
in a function)
hooks.c:1781: error: unknown field ‘hvm_set_pci_link_route’ specified in
initializer
hooks.c:1781: error: ‘flask_hvm_set_pci_link_route’ undeclared here (not
in a function)
make[4]: *** [hooks.o] Error 1


-boris

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

[Xen-devel] [linux-linus test] 104684: regressions - FAIL

2017-01-26 Thread osstest service owner 
flight 104684 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104684/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail REGR. vs. 
59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux49e555a932de57611eb27edf2d1ad03d9a267bdd
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  567 days
Failing since 59348  2015-07-10 04:24:05 Z  566 days  225 attempts
Testing same since   104684  2017-01-26 04:21:40 Z0 days1 attempts


7518 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvops

Re: [Xen-devel] [PATCH v1 2/3] x86/xen/time: setup vcpu 0 time info page

2017-01-26 Thread Joao Martins 
On 01/25/2017 07:26 PM, Boris Ostrovsky wrote:
> On 01/25/2017 12:33 PM, Joao Martins wrote:
>> In order to support pvclock vdso on xen we need to setup the time
>> info page for vcpu 0 and register the page with Xen using the
>> VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
>> will also forcefully update the pvti which will set some of the
>> necessary flags for vdso. Afterwards we check if it supports the
>> PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
>> vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
>> will be later on used when mapping the vdso image.
>>
>> The xen headers are also updated to include the new hypercall for
>> registering the secondary vcpu_time_info struct.
>>
>> Signed-off-by: Joao Martins 
>> ---
>> Changes since RFC:
>>  (Comments from Boris and David)
>>  * Remove Kconfig option
>>  * Use get_zeroed_page/free/page
>>  * Remove the hypercall availability check
>>  * Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
>>  (New)
>>  * Set secondary copy on restore such that it works on migration.
>>  * Drop global xen_clock variable and stash it locally on
>>  xen_setup_vsyscall_time_info.
>>  * WARN_ON(ret) if we fail to unregister the pvti.
>> ---
>>  arch/x86/xen/enlighten.c |  2 ++
>>  arch/x86/xen/time.c  | 51 
>> 
>>  arch/x86/xen/xen-ops.h   |  1 +
>>  include/xen/interface/vcpu.h | 28 
>>  4 files changed, 82 insertions(+)
>>
>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
>> index 51ef952..15d271d 100644
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -270,6 +270,8 @@ void xen_vcpu_restore(void)
> 
> This is called for PV only. What about HVM?
The call is missing from xen_hvm_post_suspend(...), I will add it.

> 
>>  HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL))
>>  BUG();
>>  }
>> +
>> +xen_setup_vsyscall_time_info(0);
> 
> Do we need to tear down time memory area on VCPU suspend?
I also missed that; otherwise I am leaking a page.

I could also rework this patch such that the initially allocated xen_clock page
is reused and simply register/unregister in save/restore paths. This would
probably mean adding one extra helper to register the vcpu_time info and perhaps
make xen_setup_vsyscall_time_info a bit simpler.

>>  }
>>  
>>  static void __init xen_banner(void)
>> diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
>> index 1e69956..e90f703 100644
>> --- a/arch/x86/xen/time.c
>> +++ b/arch/x86/xen/time.c
>> @@ -367,6 +367,56 @@ static const struct pv_time_ops xen_time_ops 
>> __initconst = {
>>  .steal_clock = xen_steal_clock,
>>  };
>>  
>> +int xen_setup_vsyscall_time_info(int cpu)
>> +{
>> +struct pvclock_vsyscall_time_info *xen_clock;
>> +struct vcpu_register_time_memory_area t;
>> +struct pvclock_vcpu_time_info *pvti;
>> +unsigned long addr;
>> +u8 flags;
>> +int ret;
>> +
>> +addr = get_zeroed_page(GFP_KERNEL);
>> +if (!addr)
>> +return -ENOMEM;
>> +
>> +xen_clock = (struct pvclock_vsyscall_time_info *) addr;
>> +memset(xen_clock, 0, PAGE_SIZE);
> 
> You don't really need addr 
The reason I had this was to avoid to save one cast to unsigned long (on
free_page paths). But maybe it's not worth it and looking at the rest of the
x86/xen code, this doesn't seem to be the case. I will remove it.

> and there is no reason to memset the page to
> zero, given that you got it with get_zeroed_page().
Yeap, Fixed.

> 
>> +
>> +t.addr.v = _clock->pvti;
>> +
>> +ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
>> + cpu, );
>> +
>> +if (ret) {
>> +pr_debug("xen: cannot register vcpu_time_info err %d\n", ret);
> 
> pr_warn() would be more appropriate I think. You also have blank line
> before 'if'.
Fixed.

>> +free_page(addr);
>> +return ret;
>> +}
>> +
>> +pvti = _clock->pvti;
>> +flags = pvti->flags;
> 
> I don't think you need these, given that you only reference flags once
> below.
> 
Indeed, fixed as well.

>> +
>> +if (!(flags & PVCLOCK_TSC_STABLE_BIT)) {
>> +t.addr.v = NULL;
>> +ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area,
>> + cpu, );
>> +if (!ret)
>> +free_page(addr);
>> +
>> +WARN_ON(ret);
> 
> Did someone ask for WARN_ON()? (from your changelog it looks like it
> could have been either David or me). I think pr_warn() is sufficient,
> just like above.
Looking again at previous comments no, this WARN_ON wasn't asked. I can changed
it to the similar above as you are suggesting.

> 
>> +pr_debug("xen: VCLOCK_PVCLOCK not supported\n");
> 
> pr_notice()
Fixed it too.

> 
> -boris
> 
>> +return

  1   2   >