Re: [Xen-devel] [PATCH 1/2] xen/input: use string constants from PV protocol

[Oleksandr Andrushchenko]

On 04/21/2017 05:11 AM, Dmitry Torokhov wrote:

On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in the frontend driver.

Signed-off-by: Oleksandr Andrushchenko 

I'll have to postpone it until I receive changes containing these new
string constants.

fair enough

  Otherwise it looks OK.

thank you

---
  drivers/input/misc/xen-kbdfront.c | 22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 2fc7895373ab..01c27b4c3288 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
goto error_nomem;
  
  	/* Set input abs params to match backend screen res */

-   abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
-   ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+   abs = xenbus_read_unsigned(dev->otherend,
+  XENKBD_FIELD_FEAT_ABS_POINTER, 0);
+   ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
+ XENKBD_FIELD_WIDTH,
  ptr_size[KPARAM_X]);
-   ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+   ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
+ XENKBD_FIELD_HEIGHT,
  ptr_size[KPARAM_Y]);
if (abs) {
ret = xenbus_write(XBT_NIL, dev->nodename,
-  "request-abs-pointer", "1");
+  XENKBD_FIELD_REQ_ABS_POINTER, "1");
if (ret) {
pr_warning("xenkbd: can't request abs-pointer");
abs = 0;
@@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device 
*dev,
xenbus_dev_fatal(dev, ret, "starting transaction");
goto error_irqh;
}
-   ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
+   ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
virt_to_gfn(info->page));
if (ret)
goto error_xenbus;
-   ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
+   ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
+   "%u", info->gref);
if (ret)
goto error_xenbus;
-   ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
+   ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
evtchn);
if (ret)
goto error_xenbus;
@@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
  }
  
  static const struct xenbus_device_id xenkbd_ids[] = {

-   { "vkbd" },
+   { XENKBD_DRIVER_NAME },
{ "" }
  };
  
@@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
  
  MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");

  MODULE_LICENSE("GPL");
-MODULE_ALIAS("xen:vkbd");
+MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
--
2.7.4


Thank you,
Oleksandr

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

Re: [Xen-devel] [PATCH 2/2] xen/input: add multi-touch support

[Oleksandr Andrushchenko]

Hi, Dmitry!

On 04/21/2017 05:10 AM, Dmitry Torokhov wrote:

Hi Oleksandr,

On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.

Signed-off-by: Oleksandr Andrushchenko 
---
  drivers/input/misc/xen-kbdfront.c | 142 +-
  1 file changed, 140 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 01c27b4c3288..e5d064aaa237 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include 

@@ -34,11 +35,14 @@
  struct xenkbd_info {
struct input_dev *kbd;
struct input_dev *ptr;
+   struct input_dev *mtouch;
struct xenkbd_page *page;
int gref;
int irq;
struct xenbus_device *xbdev;
char phys[32];
+   /* current MT slot/contact ID we are injecting events in */
+   int mtouch_cur_contact_id;
  };
  
  enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };

@@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
  MODULE_PARM_DESC(ptr_size,
"Pointing device width, height in pixels (default 800,600)");
  
+enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };

+static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(mtouch_size, int, NULL, 0444);
+MODULE_PARM_DESC(ptr_size,
+   "Multi-touch device width, height in pixels (default 800,600)");
+

Why do you need separate module parameters for multi-touch device?

please see below



  static int xenkbd_remove(struct xenbus_device *);
  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info 
*);
  static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
input_report_rel(dev, REL_WHEEL,
 -event->pos.rel_z);
break;
+   case XENKBD_TYPE_MTOUCH:
+   dev = info->mtouch;
+   if (unlikely(!dev))
+   break;
+   if (unlikely(event->mtouch.contact_id !=
+   info->mtouch_cur_contact_id)) {

Why is this unlikely? Does contact ID changes once in 1000 packets or
even less?

Mu assumption was that regardless of the fact that we are multi-touch
device still single touches will come in more frequently
But I can remove *unlikely* if my assumption is not correct

+   info->mtouch_cur_contact_id =
+   event->mtouch.contact_id;
+   input_mt_slot(dev, event->mtouch.contact_id);
+   }
+   switch (event->mtouch.event_type) {
+   case XENKBD_MT_EV_DOWN:
+   input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+  true);
+   input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+   event->mtouch.u.pos.abs_x);
+   input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+   event->mtouch.u.pos.abs_y);
+   input_event(dev, EV_ABS, ABS_X,
+   event->mtouch.u.pos.abs_x);
+   input_event(dev, EV_ABS, ABS_Y,
+   event->mtouch.u.pos.abs_y);
+   break;
+   case XENKBD_MT_EV_UP:
+   input_mt_report_slot_state(dev, MT_TOOL_FINGER,
+  false);
+   break;
+   case XENKBD_MT_EV_MOTION:
+   input_event(dev, EV_ABS, ABS_MT_POSITION_X,
+   event->mtouch.u.pos.abs_x);
+   input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
+   event->mtouch.u.pos.abs_y);
+   input_event(dev, EV_ABS, ABS_X,
+   event->mtouch.u.pos.abs_x);
+   input_event(dev, EV_ABS, ABS_Y,
+   event->mtouch.u.pos.abs_y);
+   break;
+   case XENKBD_MT_EV_SYN:
+   input_mt_sync_frame(dev);
+   break;
+   case XENKBD_MT_EV_SHAPE:
+   input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
+ 

Re: [Xen-devel] [PATCH 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

[Jan Beulich]

>>> On 20.04.17 at 22:40,  wrote:
> --- a/arch/x86/include/arch/msr-index.h
> +++ b/arch/x86/include/arch/msr-index.h
> @@ -38,6 +38,17 @@
>  #define MSR_GS_BASE 0xc101
>  #define MSR_SHADOW_GS_BASE  0xc102
>  
> +#define MSR_IA32_PMC(n) (0x00c1 + (n))
> +#define MSR_IA32_A_PMC(n)   (0x04c1 + (n))
> +#define MSR_IA32_PERFEVTSEL(n)  (0x0186 + (n))
> +#define MSR_IA32_FIXED_CTR(n)   (0x0309 + (n))
> +#define MSR_IA32_FIXED_CTR_CTRL 0x038d
> +#define MSR_IA32_PERF_GLOBAL_CTRL   0x038f
> +#define MSR_IA32_PERF_GLOBAL_STATUS 0x038e
> +#define MSR_IA32_PERF_GLOBAL_OVF_CTRL   0x0390
> +#define MSR_IA32_DEBUGCTL   0x01d9

Imo this should be put in the middle of PMU MSRs.

> +#define MSR_IA32_PERF_CAPABILITIES  0x0345

Overall I also think it would be nice for things to be sorted in
some way at least inside this block (perhaps numerically).

Jan


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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Jan Beulich]

>>> On 20.04.17 at 04:14,  wrote:
> On 17-04-19 03:00:29, Jan Beulich wrote:
>> >>> On 19.04.17 at 10:22,  wrote:
>> > On 17-04-18 05:46:43, Jan Beulich wrote:
>> >> >>> On 18.04.17 at 12:55,  wrote:
>> >> > I made a test patch based on v10 and attached it in mail. Could you 
>> >> > please
>> >> > help to check it? Thanks!
>> >> 
>> >> This looks reasonable at the first glance, albeit I continue to be
>> >> unconvinced that this is the only (reasonable) way of solving the
> 
> Do you have any other suggestion on this? Thanks!
> 
>> >> problem. After all we don't have to go through similar hoops for
>> >> any other of the register state associated with a vCPU. There
>> > 
>> > Sorry, I do not understand your meaning clearly.
>> > 1. DYM the ASSOC register which is set in 'psr_ctxt_switch_to'? In this 
>> > patch,
>> >we check 'dom_ids' array to know if the domain's cos id has not been 
>> > set but
>> >its 'psr_cos_ids[socket]' already has a non zero value. This case means 
>> > the
>> >socket offline has happened so that we have to restore the domain's
>> >'psr_cos_ids[socket]' to default value 0 which points to default COS 
>> > MSR.
>> >I think we have discussed this in previous mails and achieved agreement 
>> > on
>> >such logic. 
>> > 2. DYM the COS MSRs? We have discussed this before. Per your comments, when
>> >socket is online, the registers values may be modified by FW and others.
>> >So, we have to restore them to default value which is being done in
>> >'cat_init_feature'.
>> > 
>> > So, what is your exactly meaning here? Thanks!
>> 
>> Neither of the two. I'm comparing with COS/PSR-_unrelated_
>> handling of register state. After all there are other MSRs which
>> we need to put into the right state after a core comes online.
>> 
> For PSR feature, the 'cos_reg_val[]' of the feature is destroied when socket
> is offline. The values in it are all 0 when socket is online again. This 
> causes
> error when user shows the CBMs. So, we have two options when socket is online:
> 1. Read COS MSRs values and save them into 'cos_reg_val[]'.
> 2. Restore COS MSRs values and 'cos_reg_val[]' values to default CBM.
> 
> Per our discussion on v9 patch 05, we decided to adopt option 2.

Btw., having thought some more about this, putting code into the
context switch path when there is an alternative is probably the
wrong thing after all, i.e. if special treatment _is_ really needed,
doing it in less frequently executed code would likely be better.
But as before - much depends on clarifying why special treatment
is needed here, but not elsewhere (and to avoid questions, with
"elsewhere" I mean outside of PSR/CAT code - there's plenty of
other CPU register state to take as reference).

Jan


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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Jan Beulich]

>>> On 20.04.17 at 18:52,  wrote:
> So to summarise: 
> 
> On item 1: it appears that you are looking for a some more justification why 
> some of the changes were made, maybe with a rationale for some of the choices 
> that were made. Given that this is quite a complex series which has diverged 
> quite a lot from the design, the goal is to make it easier for either you (or 
> someone else) to sanity check the proposal which on the face of things look 
> OK. But you have some doubts and you can't easily check against the design as 
> it is out-of-date.
> 
> On item 2: you think something may not be quite right, but you can't really 
> decide until a couple of questions (not quite sure which, but I am sure Yi 
> can locate them) are answered.
> 
> Let me know whether this is actually true. 

Well, afaict both actually boil down to the same single question
regarding the special handling of CAT MSRs after onlining (at
runtime) a core on a socket all of whose cores had been offline,
namely considering that other CPU registers don't require any
such special treatment (in context switch code or elsewhere).

As to the design possibly being out of date - I have to admit I
didn't even check whether the accompanying documentation
has been kept up to date with the actual code changes. The
matter here really isn't with comparing with the design, but
rather whether the design choice (written down or not) was
an appropriate one.

Jan


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

Re: [Xen-devel] [PATCH 1/2] xen/input: use string constants from PV protocol

[Dmitry Torokhov]

On Thu, Apr 13, 2017 at 02:38:03PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Xen input para-virtual protocol defines string constants
> used by both back and frontend. Use those instead of
> explicit strings in the frontend driver.
> 
> Signed-off-by: Oleksandr Andrushchenko 

I'll have to postpone it until I receive changes containing these new
string constants. Otherwise it looks OK.

> ---
>  drivers/input/misc/xen-kbdfront.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 2fc7895373ab..01c27b4c3288 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -135,14 +135,17 @@ static int xenkbd_probe(struct xenbus_device *dev,
>   goto error_nomem;
>  
>   /* Set input abs params to match backend screen res */
> - abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
> - ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
> + abs = xenbus_read_unsigned(dev->otherend,
> +XENKBD_FIELD_FEAT_ABS_POINTER, 0);
> + ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend,
> +   XENKBD_FIELD_WIDTH,
> ptr_size[KPARAM_X]);
> - ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
> + ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend,
> +   XENKBD_FIELD_HEIGHT,
> ptr_size[KPARAM_Y]);
>   if (abs) {
>   ret = xenbus_write(XBT_NIL, dev->nodename,
> -"request-abs-pointer", "1");
> +XENKBD_FIELD_REQ_ABS_POINTER, "1");
>   if (ret) {
>   pr_warning("xenkbd: can't request abs-pointer");
>   abs = 0;
> @@ -271,14 +274,15 @@ static int xenkbd_connect_backend(struct xenbus_device 
> *dev,
>   xenbus_dev_fatal(dev, ret, "starting transaction");
>   goto error_irqh;
>   }
> - ret = xenbus_printf(xbt, dev->nodename, "page-ref", "%lu",
> + ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_REF, "%lu",
>   virt_to_gfn(info->page));
>   if (ret)
>   goto error_xenbus;
> - ret = xenbus_printf(xbt, dev->nodename, "page-gref", "%u", info->gref);
> + ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_RING_GREF,
> + "%u", info->gref);
>   if (ret)
>   goto error_xenbus;
> - ret = xenbus_printf(xbt, dev->nodename, "event-channel", "%u",
> + ret = xenbus_printf(xbt, dev->nodename, XENKBD_FIELD_EVT_CHANNEL, "%u",
>   evtchn);
>   if (ret)
>   goto error_xenbus;
> @@ -353,7 +357,7 @@ static void xenkbd_backend_changed(struct xenbus_device 
> *dev,
>  }
>  
>  static const struct xenbus_device_id xenkbd_ids[] = {
> - { "vkbd" },
> + { XENKBD_DRIVER_NAME },
>   { "" }
>  };
>  
> @@ -390,4 +394,4 @@ module_exit(xenkbd_cleanup);
>  
>  MODULE_DESCRIPTION("Xen virtual keyboard/pointer device frontend");
>  MODULE_LICENSE("GPL");
> -MODULE_ALIAS("xen:vkbd");
> +MODULE_ALIAS("xen:" XENKBD_DRIVER_NAME);
> -- 
> 2.7.4
> 

-- 
Dmitry

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

Re: [Xen-devel] [PATCH 2/2] xen/input: add multi-touch support

[Dmitry Torokhov]

Hi Oleksandr,

On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Extend xen_kbdfront to provide multi-touch support
> to unprivileged domains.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/input/misc/xen-kbdfront.c | 142 
> +-
>  1 file changed, 140 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 01c27b4c3288..e5d064aaa237 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -34,11 +35,14 @@
>  struct xenkbd_info {
>   struct input_dev *kbd;
>   struct input_dev *ptr;
> + struct input_dev *mtouch;
>   struct xenkbd_page *page;
>   int gref;
>   int irq;
>   struct xenbus_device *xbdev;
>   char phys[32];
> + /* current MT slot/contact ID we are injecting events in */
> + int mtouch_cur_contact_id;
>  };
>  
>  enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
> @@ -47,6 +51,12 @@ module_param_array(ptr_size, int, NULL, 0444);
>  MODULE_PARM_DESC(ptr_size,
>   "Pointing device width, height in pixels (default 800,600)");
>  
> +enum { KPARAM_MT_X, KPARAM_MT_Y, KPARAM_MT_CNT };
> +static int mtouch_size[KPARAM_MT_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> +module_param_array(mtouch_size, int, NULL, 0444);
> +MODULE_PARM_DESC(ptr_size,
> + "Multi-touch device width, height in pixels (default 800,600)");
> +

Why do you need separate module parameters for multi-touch device?

>  static int xenkbd_remove(struct xenbus_device *);
>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info 
> *);
>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> @@ -100,6 +110,60 @@ static irqreturn_t input_handler(int rq, void *dev_id)
>   input_report_rel(dev, REL_WHEEL,
>-event->pos.rel_z);
>   break;
> + case XENKBD_TYPE_MTOUCH:
> + dev = info->mtouch;
> + if (unlikely(!dev))
> + break;
> + if (unlikely(event->mtouch.contact_id !=
> + info->mtouch_cur_contact_id)) {

Why is this unlikely? Does contact ID changes once in 1000 packets or
even less?

> + info->mtouch_cur_contact_id =
> + event->mtouch.contact_id;
> + input_mt_slot(dev, event->mtouch.contact_id);
> + }
> + switch (event->mtouch.event_type) {
> + case XENKBD_MT_EV_DOWN:
> + input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> +true);
> + input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> + event->mtouch.u.pos.abs_x);
> + input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> + event->mtouch.u.pos.abs_y);
> + input_event(dev, EV_ABS, ABS_X,
> + event->mtouch.u.pos.abs_x);
> + input_event(dev, EV_ABS, ABS_Y,
> + event->mtouch.u.pos.abs_y);
> + break;
> + case XENKBD_MT_EV_UP:
> + input_mt_report_slot_state(dev, MT_TOOL_FINGER,
> +false);
> + break;
> + case XENKBD_MT_EV_MOTION:
> + input_event(dev, EV_ABS, ABS_MT_POSITION_X,
> + event->mtouch.u.pos.abs_x);
> + input_event(dev, EV_ABS, ABS_MT_POSITION_Y,
> + event->mtouch.u.pos.abs_y);
> + input_event(dev, EV_ABS, ABS_X,
> + event->mtouch.u.pos.abs_x);
> + input_event(dev, EV_ABS, ABS_Y,
> + event->mtouch.u.pos.abs_y);
> + break;
> + case XENKBD_MT_EV_SYN:
> + input_mt_sync_frame(dev);
> + break;
> + case XENKBD_MT_EV_SHAPE:
> + input_event(dev, EV_ABS, ABS_MT_TOUCH_MAJOR,
> + event->mtouch.u.shape.major);
> + input_event(dev, EV_ABS, ABS_MT_TOUCH_MINOR,
> + event->mtouch.u.shape.minor);
> +

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 21e359dccab7f3cd7b527721be042d034349417d
baseline version:
 ovmf 4395f82e7f81f5215e52f3dba523ca1ccf280823

Last test of basis71207  2017-04-20 02:17:04 Z0 days
Testing same since71212  2017-04-20 22:49:48 Z0 days1 attempts


People who touched revisions under test:
  Chen A Chen 
  Hao Wu 
  Mateusz Albecki 
  Ruiyu Ni 
  Star Zeng 
  Zhang Lubo 
  Zhang, Lubo 

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



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

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

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


Push not applicable.


commit 21e359dccab7f3cd7b527721be042d034349417d
Author: Ruiyu Ni 
Date:   Wed Apr 19 17:16:27 2017 +0800

MdeModulePkg/UefiBootManagerLib: Avoid buggy USB short-form expanding

When a load option points to a physical UsbIo controller, whose
device path contains UsbClass or UsbWwid node, old logic
unconditionally treats it as a short-form device path and expands
it. But the expanding gets the exactly same device path, and the
device path is passed to BmGetNextLoadOptionDevicePath() which
then passes this device path to BmExpandUsbDevicePath() again.
This causes a infinite recursion.

The patch avoids the USB short-form expanding when the device path
points to a physical UsbIo controller.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
Reviewed-by: Jeff Fan 
Cc: Eric Dong 
Cc: Michael Turner 

commit 52cad7d0d8e0ec94ca6152f9f7c56f48ca15825e
Author: Zhang, Lubo 
Date:   Thu Apr 6 16:58:09 2017 +0800

NetworkPkg: Fix bug related DAD issue in IP6 driver.

If we set PXEv6 as the first boot option and reboot immediately
after the first successful boot, it will assert. the root cause is
when we set the policy from manual to automatic in PXE driver,
the ip6 Configure item size is already set to zero and other
structures are also released, So it is not needed to perform DAD call
back function which is invoked by Ip6ConfigSetMaunualAddress.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
Reviewed-by: Jiaxin Wu 

commit b28bf4143d00142323d5dd9a9129b9b25d0dff56
Author: Zhang, Lubo 
Date:   Thu Apr 6 16:57:41 2017 +0800

NetworkPkg: Add check logic for iSCSI driver.

Need to check variable of mPrivate whether is
null before used and redefine the array length
of target address for keyword.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Fu Siyuan 
Reviewed-by: Jiaxin Wu 
Reviewed-by: Ye Ting 

commit 861c8dff2f506d602f8612ace12d244c29e63f31
Author: Star Zeng 
Date:   Wed Apr 19 11:12:18 2017 +0800

MdeModulePkg PiSmmCore: Enhance SMM FreePool to catch buffer overflow

This solution is equivalent to DXE core.

AllocatePool() allocates POOL_TAIL after the buffer.
This POOL_TAIL is checked at FreePool().
If the there is buffer overflow, the issue can be caught at FreePool().

This patch could also handle the eight-byte aligned allocation
requirement. The discussion related to the eight-byte aligned
allocation requirement is at
https://lists.01.org/pipermail/edk2-devel/2017-April/009995.html.

According to the PI spec (Vol 4, Section 3.2 SmmAllocatePool()):
The SmmAllocatePool() function ... All allocations are eight-byte aligned.

Cc: Jiewen Yao 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zen

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Konrad Rzeszutek Wilk]

> If this reaction of mine is not acceptable, all I can do is refrain
> from further looking at this series. And Yi, I certainly apologize
> for perhaps not doing these reviews wholeheartedly, since -
> as also expressed before - I continue to not really view this as
> very important functionality. Yet considering for how long some
> of the versions hadn't been looked at by anyone at all, the
> alternative would have been to simply let it sit further without
> looking at it. I actually take this lack of interest by others as an
> indication that I'm not the only one considering this nice to have,
> but no more.

I do have an interest in this series. And I can certainly give it
a review - but once you get your teeth in a patchset I feel it is
bit counterintuitive to review it - as you do a much much better
job that I could have.

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

[Xen-devel] [linux-arm-xen baseline-only test] 71210: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71210 linux-arm-xen real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71210/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-midway   15 guest-start/debian.repeat fail REGR. vs. 71148

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 71148
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 71148

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   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 linux92ed32019d0dd22b796608079023ce42aa8a5a57
baseline version:
 linux6878b2fa7229c9208a02d45f280c71389cba0617

Last test of basis71148  2017-04-04 10:54:11 Z   16 days
Testing same since71210  2017-04-20 11:27:31 Z0 days1 attempts


10162 people touched revisions under test,
not listing them all

jobs:
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-arm64  broken  
 build-armhf  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 test-arm64-arm64-xl  blocked 
 test-armhf-armhf-xl  pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-arm64-arm64-xl-xsm  blocked 
 test-armhf-armhf-xl-xsm  pass
 test-arm64-arm64-xl-credit2  blocked 
 test-armhf-armhf-xl-credit2  pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-armhf-armhf-xl-midway   fail
 t

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail 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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f97838bbd980a0104e16c4a12fbf514f9fa805f1
baseline version:
 xen  828aa3352f97b613bd06daf7eb1ae734262196be

Last test of basis   107539  2017-04-19 10:03:19 Z1 days
Testing same since   107553  2017-04-20 00:15:35 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chao Gao 
  Jan Beulich 
  Razvan Cojocaru 
  Roger Pau Monné 
  Ross Lagerwall 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm   

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Alistair Francis]

On Thu, Apr 20, 2017 at 12:05 PM, Eric Blake  wrote:
> On 04/20/2017 11:18 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>>
>>> On 04/20/2017 06:59 AM, Markus Armbruster wrote:
>>>

 No objection to Alistair's idea to turn this into an enumeration.
>>>
>>> Question - should the enum be more than just 'guest' and 'host'?  For
>>> example, my patch proves that we have a lot of places that handle
>>> complimentary machine commands to reset and shutdown, and that whether
>>> 'reset' triggers a reset (and the guest keeps running as if rebooted) or
>>> a shutdown is then based on the command-line arguments given to qemu.
>>> So having the enum differentiate between 'guest-reset' and
>>> 'guest-shutdown' would be a possibility, if we want the enum to have
>>> additional states.
>>
>> I don't know.  What I do know is that we better get the enum right:
>> while adding members is backwards-compatible, changing the member sent
>> for a specific trigger is not.  If we want to reserve the option to do
>> that anyway, we need suitable documentation.
>
> Or even this idea:
>
> { 'enum': 'ShutdownCause', 'data': [ 'shutdown', 'reset', 'panic' ] }
> { 'event': 'SHUTDOWN',
>   'data': { 'guest': 'bool', '*cause': 'ShutdownCause' } }
>
> where the enum can grow as we come up with ever more reasons worth
> exposing (maybe even 'qmp', 'gui' and 'interrupt' are reasonable causes
> for a host shutdown).  Our promise would be that 'guest' never changes
> for an existing shutdown reason, but that 'cause' may become more
> refined over time if someone expresses a need for having the distinction.
>
> Thoughts?

I'm not a fan of the 'guest' bool. I do see that it helps with
maintaining backwards compatibility but I think we would be better off
just getting the reasons right in the first place.

What about something that can grow in the future? We start with a
general guest shutdown that is always there and then as we add new
reasons things can be moved to use the new method or continue to use
the general one.

SHUTDOWN_HOST
SHUTDOWN_HOST_GUI
/* This is always a backwards compatible fall-back
 * Maybe this could be SHUTDOWN_GUEST_UNKNOWN instead?
 */
SHUTDOWN_GUEST_GENERAL
SHUTDOWN_GUEST_HALT
SHUTDOWN_GUEST_RESET
...

That way we can guarantee the base coverage but still expand more
specific reasons in the future.

I guess the only problem is that then the reasons aren't always
reliable then as we could introduce a new reason and something gets
stuck using the general fall back.

Thanks,

Alistair

>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 21e359dccab7f3cd7b527721be042d034349417d
baseline version:
 ovmf 4395f82e7f81f5215e52f3dba523ca1ccf280823

Last test of basis   107545  2017-04-19 17:14:46 Z1 days
Failing since107554  2017-04-20 02:48:38 Z0 days2 attempts
Testing same since   107564  2017-04-20 13:15:04 Z0 days1 attempts


People who touched revisions under test:
  Chen A Chen 
  Hao Wu 
  Mateusz Albecki 
  Ruiyu Ni 
  Star Zeng 
  Zhang Lubo 
  Zhang, Lubo 

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=21e359dccab7f3cd7b527721be042d034349417d
+ . ./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 
21e359dccab7f3cd7b527721be042d034349417d
+ branch=ovmf
+ revision=21e359dccab7f3cd7b527721be042d034349417d
+ . ./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
+ '[' x21e359dccab7f3cd7b527721be042d034349417d = 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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Stefano Stabellini]

On Thu, 20 Apr 2017, Julien Grall wrote:
> == Cross-compiling ==
> 
> Anastasios: We are looking at support Xen in Buildroot. The use case is a
> small initramfs.
> 
> Potential task: Keep Xen updated on buildroot. Anastasios could help on that.
> 
> Stefano: Xen is compiling fine with Yocto.
> 
> ACTION: Stefano to write a wiki page about using meta-virtualization on Yocto.

I wrote the following wiki page, let me know if it works for you:

https://wiki.xenproject.org/wiki/Xen_on_ARM_and_Yocto

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

[Xen-devel] [linux-4.9 test] 107558: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail 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-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linuxc3582cc56eac9213b32cc2a2886b11e2e5027598
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z   10 days
Failing since107396  2017-04-12 11:15:19 Z8 days   16 attempts
Testing same since   107502  2017-04-18 13:18:18 Z2 days4 attempts


People who touched revisions under test:
  Adrian Hunter 
  Alan Stern 
  Alberto Aguirre 
  Alex Deucher 
  Alex Williamson 
  Alex Wood 
  Alexander Polakov 
  Alexander Polyakov 
  Amit Pundir 
  Andrew Morton 
  Andrey Konovalov 
  Andrey Smetanin 
  Andy Gross 
  Andy Shevchenko 
  Arend van Spriel 
  Arnd Bergmann 
  Aurelien Aptel 
  Baoyou Xie 
  Bartosz Golaszewski 
  Bastien Nocera 
  Ben Segall 
  Benjamin Herrenschmidt 
  Benjamin Tissoires 
  Bjorn Helgaas 
  Bjørn Mork 
  Boris Brezillon 
  Brian Norris 
  Brian Norris 
  bseg...@google.com 
  Calvin Owens 
  Chen-Yu Tsai 
  Chris Salls 
  Chris Wilson 
  Christoffer Dall 
  Christoph Hellwig 
  Chuck Lever 
  Colin Ian King 
  Corentin Chary 
  Daniel Golle 
  Daniel Lezcano 
  Daniel Vetter 
  Daniel Vetter 
  Darren Hart 
  Darrick J. Wong 
  David S. Miller 
  Dmitry Bilunov 
  Dmitry Torokhov 
  Dongdong Liu 
  Eric Dumazet 
  Eugenia Emantayev 
  Felipe Balbi 
  Felipe Balbi 
  Frederic Barrat 
  Gabriel Krisman Bertazi 
  Geer

[Xen-devel] [PATCH 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

[Mohit Gambhir]

This patch adds Intel PMU MSR addresses as macros for VPMU testing

Signed-off-by: Mohit Gambhir 
---
 arch/x86/include/arch/msr-index.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/include/arch/msr-index.h 
b/arch/x86/include/arch/msr-index.h
index 2e90079..7df9097 100644
--- a/arch/x86/include/arch/msr-index.h
+++ b/arch/x86/include/arch/msr-index.h
@@ -38,6 +38,17 @@
 #define MSR_GS_BASE 0xc101
 #define MSR_SHADOW_GS_BASE  0xc102
 
+#define MSR_IA32_PMC(n) (0x00c1 + (n))
+#define MSR_IA32_A_PMC(n)   (0x04c1 + (n))
+#define MSR_IA32_PERFEVTSEL(n)  (0x0186 + (n))
+#define MSR_IA32_FIXED_CTR(n)   (0x0309 + (n))
+#define MSR_IA32_FIXED_CTR_CTRL 0x038d
+#define MSR_IA32_PERF_GLOBAL_CTRL   0x038f
+#define MSR_IA32_PERF_GLOBAL_STATUS 0x038e
+#define MSR_IA32_PERF_GLOBAL_OVF_CTRL   0x0390
+#define MSR_IA32_DEBUGCTL   0x01d9
+#define MSR_IA32_PERF_CAPABILITIES  0x0345
+
 #endif /* XFT_X86_MSR_INDEX_H */
 
 /*
-- 
2.9.3


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

[Xen-devel] [PATCH 2/2][XTF] xtf/vpmu: MSR read/write tests for VPMU

[Mohit Gambhir]

This patch tests VPMU functionality in the hypervisor on Intel machines.
The tests write to all valid bits in the MSRs that get exposed to the guests
when VPMU is enabled. The tests also write invalid values to the bits
that should be masked and expect the wrmsr call to fault.

The tests are currently unsupported for AMD machines and PV guests.

Signed-off-by: Mohit Gambhir 
---
 tests/vpmu/Makefile |   9 +
 tests/vpmu/main.c   | 502 
 2 files changed, 511 insertions(+)
 create mode 100644 tests/vpmu/Makefile
 create mode 100644 tests/vpmu/main.c

diff --git a/tests/vpmu/Makefile b/tests/vpmu/Makefile
new file mode 100644
index 000..1eaf436
--- /dev/null
+++ b/tests/vpmu/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME  := vpmu
+CATEGORY  := utility
+TEST-ENVS := $(ALL_ENVIRONMENTS)
+
+obj-perenv += main.o
+
+include $(ROOT)/build/gen.mk
diff --git a/tests/vpmu/main.c b/tests/vpmu/main.c
new file mode 100644
index 000..849c30a
--- /dev/null
+++ b/tests/vpmu/main.c
@@ -0,0 +1,502 @@
+/**
+ * @file tests/vpmu/main.c
+ * @ref test-vpmu
+ *
+ * @page test-vpmu vpmu
+ *
+ * Test MSRs exposed by VPMU for various versions of Architectural Performance
+ * Monitoring Unit
+ *
+ * @see tests/vpmu/main.c
+ */
+
+#include 
+#include 
+#include 
+
+#define EVENT_UOPS_RETIRED   0x004101c2
+#define EVENT_UOPS_RETIRED_ANYTHREAD 0x006101c2
+#define FIXED_CTR_CTL_BITS   4
+#define FIXED_CTR_ENABLE 0x000A
+#define FIXED_CTR_ENABLE_ANYTHREAD   0x000E
+#define IA32_PERFEVENTSELx_ENABLE_ANYTHREAD  (1ull << 21)
+#define IA32_PERFEVENTSELx_ENABLE_PCB(1ull << 19)
+#define IA32_DEBUGCTL_Freeze_LBR_ON_PMI  (1ull << 11)
+#define IA32_DEBUGCTL_Freeze_PerfMon_On_PMI  (1ull << 12)
+
+const char test_title[] = "Test vpmu";
+
+static void get_intel_pmu_version(uint8_t *v, uint8_t *ng, uint8_t *nf,
+  uint8_t *ngb)
+{
+/* Inter Software Development Manual Vol 2A
+ * Table 3-8  Information Returned by CPUID Instruction */
+
+uint32_t leaf = 0x0a, subleaf = 0;
+
+uint32_t eax, ebx, ecx, edx;
+
+cpuid_count(leaf, subleaf, &eax, &ebx, &ecx, &edx);
+
+/* Extract the version ID - EAX 7:0 */
+*v =  (eax & 0xff);
+
+/* Extract number of general purpose counter regs - EAX 15:8 */
+*ng = (eax >> 8) & 0xff;
+
+/* Extract number of fixed function counter regs - EDX 4:0 */
+*nf = edx & 0x1f;
+
+/* Extract number of bits in general purpose counter registers bits */
+*ngb = (eax >> 16)  & 0xff;
+}
+
+static bool test_valid_msr_write(uint32_t idx, uint64_t wval)
+{
+const char *pfx = "Error: test_valid_msr_write:";
+
+uint64_t rval = 0;
+
+printk("Writing 0x%" PRIx64 " to MSR 0x%x\n", wval, idx);
+
+if( wrmsr_safe(idx, wval) )
+{
+xtf_error("%s wrmsr for MSR 0x%x resulted in a fault!\n", pfx, idx);
+return false;
+}
+
+/* check to see if the values were written correctly */
+if ( rdmsr_safe(idx, &rval) )
+{
+xtf_error("%s rdmsr for MSR 0x%x resulted in a fault!\n", pfx, idx);
+return false;
+}
+if ( rval != wval )
+{
+xtf_error("%s rdmsr value mismatch for MSR 0x%x Expected: %"PRIx64
+", Found %"PRIx64"\n", pfx, idx, wval, rval);
+return false;
+}
+
+return true;
+}
+
+static bool test_invalid_msr_write(uint32_t idx, uint64_t wval)
+{
+printk("Write invalid value %"PRIx64" to MSR 0x%x\n", wval, idx);
+
+/* wrmsr_safe must return false after faulting */
+if( !wrmsr_safe(idx, wval) )
+{
+xtf_error("Error: test_invalid_msr_write wrmsr for MSR 0x%x did not "
+  "fault!\n", idx);
+return false;
+}
+
+printk("wrmsr to MSR 0x%x faulted as expected.\n", idx);
+
+return true;
+}
+
+static bool test_transparent_msr_write(uint32_t idx, uint64_t wval)
+{
+const char *pfx = "Error: test_transparent_msr_write:";
+
+uint64_t rval1 = 0;
+
+uint64_t rval2 = 0;
+
+printk("Attempting to write a value with no effect to MSR 0x%x\n", idx);
+
+/* read current value */
+if ( rdmsr_safe(idx, &rval1) )
+{
+xtf_error("%s rdmsr for MSR 0x%x resulted in a fault\n", pfx, idx);
+return false;
+}
+
+/* wrmsr should not fault but should not write anything either */
+if  ( wrmsr_safe(idx, wval) )
+{
+xtf_error("%s wrmsr for MSR 0x%x resulted in a fault\n", pfx, idx);
+return false;
+}
+
+/* read new value */
+if ( rdmsr_safe(idx, &rval2) )
+{
+xtf_error("%s rdmsr for MSR 0x%x resulted in a fault\n", pfx, idx);
+return false;
+}
+
+/* Check if the new value is the same as the one before wrmsr */
+
+if ( rval1 != rval2 )
+{
+xtf_error("%s rdmsr value mismatch for MSR 0x%x Expected %"PRIx64
+". Found %"PRIx64"\n", pfx, id

[Xen-devel] [PATCH 0/2][XTF] xtf/vpmu VPMU tests

[Mohit Gambhir]

This patch series adds tests to validate VPMU functionality on x86. The tests
write and read PMU MSRs to make sure that that they have been exposed
correctly.

The ultimate goal is to address security vulnerabilities, if any, that are
vaguely mentioned in XSA-163 and make VPMU available to guests with reasonable
caveats.

Further testing is required to validate the MSR state save/restore functionality
of the VPMU, concurrent usage of the counters by a number of guests and analyze 
if any other non-PMU MSRs have been exposed incorrectly.

Mohit Gambhir (2):
  xtf/vpmu: Add Intel PMU MSR addresses
  xtf/vpmu: MSR read/write tests for VPMU

 arch/x86/include/arch/msr-index.h |  11 +
 tests/vpmu/Makefile   |   9 +
 tests/vpmu/main.c | 502 ++
 3 files changed, 522 insertions(+)
 create mode 100644 tests/vpmu/Makefile
 create mode 100644 tests/vpmu/main.c

--
2.9.3


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

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Eric Blake]

On 04/19/2017 05:22 PM, Eric Blake wrote:
> Libvirt would like to be able to distinguish between a SHUTDOWN
> event triggered solely by guest request and one triggered by a
> SIGTERM or other action on the host.  qemu_kill_report() is
> already able to tell whether a shutdown was triggered by a host
> signal (but NOT by a host UI event, such as clicking the X on
> the window), but that information was then lost after being
> printed to stderr.
> 
> Enhance the shutdown request path to take a parameter of which
> way it is being triggered, and update ALL callers.  It would have
> been less churn to keep the common case with no arguments as
> meaning guest-triggered, and only modified the host-triggered
> code paths, via a wrapper function, but then we'd still have to
> audit that I didn't miss any host-triggered spots; changing the
> signature forces us to double-check that I correctly categorized
> all callers.
> 
> Here is output from 'virsh qemu-monitor-event --loop' with the
> patch installed:
> 
> event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true}
> event STOP at 1492639680.732116 for domain fedora_13: 
> event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false}

Another reason I'll need a v3: at least qemu-iotests 87 has to be
updated for new expected output.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Volodymyr Babchuk]

Hi Stefano,

On 12 April 2017 at 22:17, Stefano Stabellini  wrote:
> On Wed, 12 Apr 2017, Dario Faggioli wrote:
>> On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote:
>> > On Fri, 7 Apr 2017, Stefano Stabellini wrote:
>> > >
>> > > This is the most difficult problem that we need to solve as part of
>> > > this
>> > > work. It is difficult to have the right answer at the beginning,
>> > > before
>> > > seeing any code. If the app_container/app_thread approach causes
>> > > too
>> > > much duplication of work, the alternative would be to fix/improve
>> > > stubdoms (minios) until they match what we need. Specifically,
>> > > these
>> > > would be the requirements:
>> > >
>> >
>> IMO, this stubdom way, is really really really interesting! :-)
>>
>> > > 1) Determinism: a stubdom servicing a given guest needs to be
>> > > scheduled
>> > >immediately after the guest vcpu traps into Xen. It needs to
>> > >deterministic.
>> >
>> Something like this is in my plan since long time. Being able to /
>> having help for making it happen would be *great*!
>>
>> So, if I'm the scheduler, can you tell  me exactly when a vcpu blocks
>> waiting for a service from the vcpu of an app/stubdom (as opposed to,
>> going to sleep, waiting for other, unrelated, event, etc), and which
>> one?
>>
>> If yes... That'd be a good start.
>
> Yes, I think so.
Yep, it would be great to have support for apps from scheduler. At this moment
I have no clear vision on how that should look, thought.
>
>> > >  The stubdom vcpu has to be scheduled on the same pcpu.
>> > >This is probably the most important missing thing at the moment.
>> > >
>> That's interesting --similar to what I had in mind, even-- but needs
>> thinking.
>>
>> E.g., if the stubdom/app is multi-vcpu, which of its vcpu would you
>> schedule? And how can we be sure that what will run on that vcpu of the
>> stubdom is _exactly_ the process that will deal with the request the
>> "real gust" is waiting on?
>>
>> TBH, this is much more of an issue if we think of doing something like
>> this for driver domain too, while in the stubdom case it indeed
>> shouldn't be impossible, but still...
>>
>> (And stubdoms, especially minios ones, are the ones I know less, so
>> bear with me a bit.)
>
> We would have one app per emulator. Each app would register an MMIO
> range or instruction set to emulate. On a guest trap, Xen figures out
> which app it needs to run.
I't is not best approach, I think. For example we need one SMC handler for
all domains. Because that SMC handler should track execution state of different
guests to help TEE with scheduling. You know, TEE can't block in secure state,
so it returns back and blocks in kernel driver. SMC handler need to know
which guest it needs to wake up when times comes.

The same story with virtual coprocessors, I think.

On other hand, MMIO handler can be one per domain. So, it should be
configurable. Or, maybe we need per-app MMIO handler and one global SMC handler.
Perhaps, we need to think about all possible use cases.

> With the app model, we would run the app on the same physical cpu where
> the guest vcpu trapped, always starting from the same entry point of the
> app. You could run as many app instances concurrently as the number of
> guest vcpus on different pcpus.
>
> There are no stubdom processes, only a single entry point and a single
> address space.
Right

>
>> > > 2) Accounting: memory and cpu time of a stubdom should be accounted
>> > >agaist the domain it is servicing. Otherwise it's not fair.
>> > >
>> Absolutely.
>>
>> > > 3) Visibility: stub domains and vcpus should be marked differently
>> > > from other
>> > >vcpus as not to confuse the user. Otherwise "xl list" becomes
>> > >confusing.
>> > >
>> Well, may seem unrelated, but will you schedule the subdom _only_ in
>> this kind of "donated time slots" way?
>
> Yes
>
>
>> > > 1) and 2) are particularly important. If we had them, we would not
>> > > need
>> > > el0 apps. I believe stubdoms would be as fast as el0 apps too.
>> >
>> > CC'ing George and Dario. I was speaking with George about this topic,
>> > I'll let him explain his view as scheduler maintainer, but he
>> > suggested
>> > to avoid scheduler modifications (all schedulers would need to be
>> > taught to handle this) and extend struct vcpu for el0 apps instead.
>> >
>> Yeah, thanks Stefano. I'm back today after being sick for a couple of
>> days, so I need to catch up with this thread, and I will.
>>
>> In general, I like the idea of enhancing stubdoms for this, and I'll
>> happily participate in design and development of that.
>
> That would be great!



-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

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

[osstest service owner]

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

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
 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  de22e0dd0df7244052b978fdd939aae7a0937077
baseline version:
 xen  f9e2600ea107bf408a2778f456bd1beee29ce3c1

Last test of basis   107563  2017-04-20 13:01:22 Z0 days
Testing same since   107569  2017-04-20 18:01:33 Z0 days1 attempts


People who touched revisions under test:
  Eric DeVolder 
  Julien Grall 
  Ross Lagerwall 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 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=de22e0dd0df7244052b978fdd939aae7a0937077
+ . ./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 
de22e0dd0df7244052b978fdd939aae7a0937077
+ branch=xen-unstable-smoke
+ revision=de22e0dd0df7244052b978fdd939aae7a0937077
+ . ./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
+ '[' xde22e0dd0df7244052b978fdd939aae7a0937077 = 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.gi

[Xen-devel] [qemu-mainline test] 107557: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
107542 pass in 107557
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 107542 pass 
in 107557
 test-armhf-armhf-xl-multivcpu  6 xen-bootfail in 107542 pass in 107557
 test-amd64-amd64-amd64-pvgrub  9 debian-di-install fail pass in 107542

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

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
 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
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-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
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuca55019dacb821cc675273237a5173fc67bf3230
baseline version:
 qemuu9c6b899f7a46893ab3b671e341a2234e9c0c060e

Last test of basis   107501  2017-04-18 13:18:16 Z2 days
Testing same since   107531  2017-04-18 23:46:16 Z1 days3 attempts


People who touched revisions under test:
  Fam Zheng 
  Jeff Cody 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Eric Blake]

On 04/20/2017 11:18 AM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> On 04/20/2017 06:59 AM, Markus Armbruster wrote:
>>
>>>
>>> No objection to Alistair's idea to turn this into an enumeration.
>>
>> Question - should the enum be more than just 'guest' and 'host'?  For
>> example, my patch proves that we have a lot of places that handle
>> complimentary machine commands to reset and shutdown, and that whether
>> 'reset' triggers a reset (and the guest keeps running as if rebooted) or
>> a shutdown is then based on the command-line arguments given to qemu.
>> So having the enum differentiate between 'guest-reset' and
>> 'guest-shutdown' would be a possibility, if we want the enum to have
>> additional states.
> 
> I don't know.  What I do know is that we better get the enum right:
> while adding members is backwards-compatible, changing the member sent
> for a specific trigger is not.  If we want to reserve the option to do
> that anyway, we need suitable documentation.

Or even this idea:

{ 'enum': 'ShutdownCause', 'data': [ 'shutdown', 'reset', 'panic' ] }
{ 'event': 'SHUTDOWN',
  'data': { 'guest': 'bool', '*cause': 'ShutdownCause' } }

where the enum can grow as we come up with ever more reasons worth
exposing (maybe even 'qmp', 'gui' and 'interrupt' are reasonable causes
for a host shutdown).  Our promise would be that 'guest' never changes
for an existing shutdown reason, but that 'cause' may become more
refined over time if someone expresses a need for having the distinction.

Thoughts?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 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
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 11 guest-start  fail  never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-amd64-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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linuxf61143c45077df4fa78e2f1ba455a00bbe1d5b8c
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  651 days
Failing since 59348  2015-07-10 04:24:05 Z  650 days  399 attempts
Testing same since   107555  2017-04-20 04:18:55 Z0 days1 attempts


8169 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-amd64-amd64-xl  pass
 test-arm64-arm64-xl  fail
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-amd64-x

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Eric Blake]

On 04/20/2017 11:12 AM, Markus Armbruster wrote:

>>> Well technically /usr/sbin/halt just terminates all processes / kernel and
>>> halts CPUs, but the virtual machine is still active (and a 'reset' in the
>>> monitor can start it again. /usr/sbin/poweroff is what actually does the
>>> ACPI poweroff to trigger QEMU to exit[1]
>>
>> I'm thinking of this wording:
>>
>> triggered by a guest request (such as the guest running
>> /usr/sbin/poweroff to trigger an ACPI shutdown or machine halt instruction)
> 
> A quick glance at the patch suggests the instructions in question are
> typically writes to some device register.  I wouldn't call them "halt
> instructions", in particular since there's the x86 "hlt" instruction
> that does something else.

Then maybe: a guest request (such as the guest running
/usr/sbin/poweroff to trigger an ACPI or other hardware-specific
shutdown sequence)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Julien Grall]

Hi,

On 18/04/17 19:51, Juergen Gross wrote:

On 18/04/17 20:46, Stefano Stabellini wrote:

On Tue, 18 Apr 2017, Juergen Gross wrote:

On 18/04/17 20:37, Stefano Stabellini wrote:

On Thu, 6 Apr 2017, Juergen Gross wrote:

On 06/04/17 18:43, Daniel Kiper wrote:

On Thu, Apr 06, 2017 at 06:22:44PM +0200, Juergen Gross wrote:

On 06/04/17 18:06, Daniel Kiper wrote:

Hi Julien,

On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:

Hi Daniel,

On 06/04/17 16:20, Daniel Kiper wrote:

On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gross wrote:

On 06/04/17 16:27, Daniel Kiper wrote:

On Thu, Apr 06, 2017 at 09:32:32AM +0100, Julien Grall wrote:

Hi Juergen,

On 06/04/17 07:23, Juergen Gross wrote:

On 05/04/17 21:49, Boris Ostrovsky wrote:

On 04/05/2017 02:14 PM, Julien Grall wrote:

The x86 code has theoritically a similar issue, altought EFI does not
seem to be the preferred method. I have left it unimplemented on x86 and
CCed Linux Xen x86 maintainers to know their view here.


(+Daniel)

This could be a problem for x86 as well, at least theoretically.
xen_machine_power_off() may call pm_power_off(), which is efi.reset_system.

So I think we should have a similar routine there.


+1

I don't see any problem with such a routine added, in contrast to
potential "reboots" instead of power off without it.

So I think this dummy xen_efi_reset_system() should be added to
drivers/xen/efi.c instead.


I will resend the patch during day with xen_efi_reset_system moved
to common code and implement the x86 counterpart (thought, I will
not be able to test it).


I think that this is ARM specific issue. On x86 machine_restart() calls
xen_restart(). Hence, everything works. So, I think that it should be
fixed only for ARM. Anyway, please CC me when you send a patch.


What about xen_machine_power_off() (as stated in Boris' mail)?


Guys what do you think about that:

--- a/drivers/firmware/efi/reboot.c
+++ b/drivers/firmware/efi/reboot.c
@@ -55,7 +55,7 @@ static void efi_power_off(void)

static int __init efi_shutdown_init(void)
{
-   if (!efi_enabled(EFI_RUNTIME_SERVICES))
+   if (!efi_enabled(EFI_RUNTIME_SERVICES) || efi_enabled(EFI_PARAVIRT))
   return -ENODEV;

   if (efi_poweroff_required())


Julien, for ARM64 please take a look at 
arch/arm64/kernel/efi.c:efi_poweroff_required(void).

I hope that tweaks for both files should solve our problem.


This sounds good for power off (I haven't tried to power off DOM0
yet). But this will not solve the restart problem (see
machine_restart in arch/arm64/kernel/process.c) which call directly
efi_reboot.


Hmmm... It seems to me that efi.reset_system override with empty function
in arch/arm/xen/efi.c is the best solution. So, I see three patches here.
One for drivers/firmware/efi/reboot.c, one for arch/arm/xen/efi.c and one
for arch/arm64/kernel/efi.c. Does it make sense?


I still think the empty function should be in drivers/xen/efi.c and we
should use it in arch/x86/xen/efi.c, too.


If you wish we can go that way too. Though I thing that we should fix
drivers/firmware/efi/reboot.c:efi_shutdown_init() too. Just in case.


Sure, go ahead. I won't object.


For the Xen on ARM side, the original patch that started this thread
(20170405181417.15985-1-julien.gr...@arm.com) is good to go, right?



As I said: the dummy xen_efi_reset_system() should be in
drivers/xen/efi.c


OK. Who is working on it?


Didn't Julien say he would do it?


Yes. I looked at bit closer to the problem mention with power off. 
xen_efi_reset_system cannot be a NOP because there may not be fallback 
alternatives (see machine_power_off in arch/arm64/kernel/process.c)


So I think we would have to translate EFI_RESET* to Xen SHUTDOWN_* and 
then call HYPERVISOR_sched_op directly.


I will send a new version soon.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

[Stefano Stabellini]

On Thu, 20 Apr 2017, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 20 April 2017 00:02
> > To: Paul Durrant 
> > Cc: 'Stefano Stabellini' ; qemu-de...@nongnu.org;
> > Anthony Perard ; Wei Liu
> > ; jgr...@suse.com; julien.gr...@arm.com; xen-
> > de...@lists.xenproject.org
> > Subject: RE: QEMU build breakage on ARM against Xen 4.9 caused by
> > libxendevicemodel
> > 
> > On Wed, 19 Apr 2017, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > > > Sent: 18 April 2017 18:41
> > > > To: Paul Durrant 
> > > > Cc: 'Stefano Stabellini' ; qemu-
> > de...@nongnu.org;
> > > > Anthony Perard ; Wei Liu
> > > > ; jgr...@suse.com; julien.gr...@arm.com; xen-
> > > > de...@lists.xenproject.org
> > > > Subject: RE: QEMU build breakage on ARM against Xen 4.9 caused by
> > > > libxendevicemodel
> > > >
> > > > On Tue, 18 Apr 2017, Paul Durrant wrote:
> > > > > > -Original Message-
> > > > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > > > > > Sent: 15 April 2017 01:40
> > > > > > To: Stefano Stabellini 
> > > > > > Cc: Paul Durrant ; qemu-
> > de...@nongnu.org;
> > > > > > Anthony Perard ; Wei Liu
> > > > > > ; jgr...@suse.com; julien.gr...@arm.com; xen-
> > > > > > de...@lists.xenproject.org
> > > > > > Subject: Re: QEMU build breakage on ARM against Xen 4.9 caused by
> > > > > > libxendevicemodel
> > > > > >
> > > > > > On Fri, 14 Apr 2017, Stefano Stabellini wrote:
> > > > > > > Hi Paul,
> > > > > > >
> > > > > > > The following commit in my qemu "next" branch breaks the build on
> > > > arm
> > > > > > > and arm64:
> > > > > > >
> > > > > > > commit 670271647ad15e9d937ced7a72c892349c709216
> > > > > > > Author: Paul Durrant 
> > > > > > > Date:   Tue Mar 7 10:55:34 2017 +
> > > > > > >
> > > > > > > xen: use libxendevicemodel when available
> > > > > > >
> > > > > > > See the appended build log. Sorry for not realizing it sooner.
> > > > > >
> > > > > > As I imagined, this bug is easy to solve. It is reproducible on x86 
> > > > > > too,
> > > > > > if you pass -DXC_WANT_COMPAT_DEVICEMODEL_API=1 to configure
> > > > and
> > > > > > forcefully disable Xen 4.9 detection in the configure script.
> > > > > >
> > > > > > If QEMU detects xen_ctrl_version = 480, the build will fail against 
> > > > > > Xen
> > > > > > 4.9, even when -DXC_WANT_COMPAT_DEVICEMODEL_API=1 is
> > > > specified.
> > > > > >
> > > > > > The appended patch solves the problem. However, Xen 4.9 detection
> > > > and
> > > > > > compilation remain broken.
> > > > >
> > > > > Ok, that fix looks fine to me.
> > > >
> > > > I merged this change into "use libxendevicemodel when available" in my
> > > > next branch.
> > > >
> > > > Are you going to take care of getting the QEMU build on ARM to work
> > > > against Xen 4.9 (properly detecting 4.9, without
> > > > -DXC_WANT_COMPAT_DEVICEMODEL_API=1)?
> > > >
> > >
> > > I can take a look once I get access to some h/w. Since the 4.9 detection
> > should merely be based upon the presence of libxendevicemodel, I can't
> > really imagine why ARM should behave any differently to x86.
> > 
> > I managed to find the time to do some debugging. You are right that is
> > not anything major. The bug is due to a missing -lxencall in the QEMU
> > configure script, I wonder why it works on x86.
> 
> Yes, that's weird. libxendevicemodel does depend on libxencall for the case 
> when the privcmd driver in dom0 does not support the new DM_OP ioctl, but 
> that dependency should be there regardless of architecture.
> 
> > 
> > diff --git a/configure b/configure
> > index 99d6cbc..363a126 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2027,9 +2027,9 @@ int main(void) {
> >return 0;
> >  }
> >  EOF
> > -compile_prog "" "$xen_libs $xen_stable_libs -lxendevicemodel"
> > +compile_prog "" "$xen_libs $xen_stable_libs -lxendevicemodel -
> > lxencall"
> >then
> > -  xen_stable_libs="$xen_stable_libs -lxendevicemodel"
> > +  xen_stable_libs="$xen_stable_libs -lxendevicemodel -lxencall"
> >xen_ctrl_version=40900
> >xen=yes
> >  elif
> 
> I think xencall should be part of the base xen_stable_libs anyway.

Yes, you are right. However I noticed that -lxencall needs to come after
-lxendevicemodel. So, I'll have to move -lxendevicemodel before
$xen_stable_libs, see below. I'll merge this patch into "configure:
detect presence of libxendevicemodel", if that's OK.

diff --git a/configure b/configure
index 99d6cbc..3133ef8 100755
--- a/configure
+++ b/configure
@@ -1992,7 +1992,7 @@ if test "$xen" != "no" ; then
   else
 
 xen_libs="-lxenstore -lxenctrl -lxenguest"
-xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
+xen_stable_libs="-lxencall -lxenforeignmemory -lxengnttab -lxenevtchn"
 
 # First we test whether Xen headers and libraries are available.
 # If no, we are done an

[Xen-devel] [PATCH 1/4] hvm/dmop: Box dmop_args rather than passing multiple parameters around

[jennifer.herbert]

From: Jennifer Herbert 

No functional change.

Signed-off-by: Jennifer Herbert 
Signed-off-by: Andrew Cooper 
--
CC: Paul Durrant 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Julien Grall 
---
 xen/arch/x86/hvm/dm.c | 47 ---
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index d72b7bd..fb4bcec 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -25,6 +25,13 @@
 
 #include 
 
+struct dmop_args {
+domid_t domid;
+unsigned int nr_bufs;
+/* Reserve enough buf elements for all current hypercalls. */
+struct xen_dm_op_buf buf[2];
+};
+
 static bool copy_buf_from_guest(const xen_dm_op_buf_t bufs[],
 unsigned int nr_bufs, void *dst,
 unsigned int idx, size_t dst_size)
@@ -287,16 +294,14 @@ static int inject_event(struct domain *d,
 return 0;
 }
 
-static int dm_op(domid_t domid,
- unsigned int nr_bufs,
- xen_dm_op_buf_t bufs[])
+static int dm_op(struct dmop_args *op_args)
 {
 struct domain *d;
 struct xen_dm_op op;
 bool const_op = true;
 long rc;
 
-rc = rcu_lock_remote_domain_by_id(domid, &d);
+rc = rcu_lock_remote_domain_by_id(op_args->domid, &d);
 if ( rc )
 return rc;
 
@@ -307,7 +312,7 @@ static int dm_op(domid_t domid,
 if ( rc )
 goto out;
 
-if ( !copy_buf_from_guest(bufs, nr_bufs, &op, 0, sizeof(op)) )
+if ( !copy_buf_from_guest(&op_args->buf[0], op_args->nr_bufs, &op, 0, 
sizeof(op)) )
 {
 rc = -EFAULT;
 goto out;
@@ -466,10 +471,10 @@ static int dm_op(domid_t domid,
 if ( data->pad )
 break;
 
-if ( nr_bufs < 2 )
+if ( op_args->nr_bufs < 2 )
 break;
 
-rc = track_dirty_vram(d, data->first_pfn, data->nr, &bufs[1]);
+rc = track_dirty_vram(d, data->first_pfn, data->nr, &op_args->buf[1]);
 break;
 }
 
@@ -564,7 +569,7 @@ static int dm_op(domid_t domid,
 
 if ( (!rc || rc == -ERESTART) &&
  !const_op &&
- !copy_buf_to_guest(bufs, nr_bufs, 0, &op, sizeof(op)) )
+ !copy_buf_to_guest(&op_args->buf[0], op_args->nr_bufs, 0, &op, 
sizeof(op)) )
 rc = -EFAULT;
 
  out:
@@ -587,20 +592,21 @@ CHECK_dm_op_set_mem_type;
 CHECK_dm_op_inject_event;
 CHECK_dm_op_inject_msi;
 
-#define MAX_NR_BUFS 2
-
 int compat_dm_op(domid_t domid,
  unsigned int nr_bufs,
  XEN_GUEST_HANDLE_PARAM(void) bufs)
 {
-struct xen_dm_op_buf nat[MAX_NR_BUFS];
+struct dmop_args args;
 unsigned int i;
 int rc;
 
-if ( nr_bufs > MAX_NR_BUFS )
+if ( nr_bufs > ARRAY_SIZE(args.buf) )
 return -E2BIG;
 
-for ( i = 0; i < nr_bufs; i++ )
+args.domid = domid;
+args.nr_bufs = nr_bufs;
+
+for ( i = 0; i < args.nr_bufs; i++ )
 {
 struct compat_dm_op_buf cmp;
 
@@ -610,12 +616,12 @@ int compat_dm_op(domid_t domid,
 #define XLAT_dm_op_buf_HNDL_h(_d_, _s_) \
 guest_from_compat_handle((_d_)->h, (_s_)->h)
 
-XLAT_dm_op_buf(&nat[i], &cmp);
+XLAT_dm_op_buf(&args.buf[i], &cmp);
 
 #undef XLAT_dm_op_buf_HNDL_h
 }
 
-rc = dm_op(domid, nr_bufs, nat);
+rc = dm_op(&args);
 
 if ( rc == -ERESTART )
 rc = hypercall_create_continuation(__HYPERVISOR_dm_op, "iih",
@@ -628,16 +634,19 @@ long do_dm_op(domid_t domid,
   unsigned int nr_bufs,
   XEN_GUEST_HANDLE_PARAM(xen_dm_op_buf_t) bufs)
 {
-struct xen_dm_op_buf nat[MAX_NR_BUFS];
+struct dmop_args args;
 int rc;
 
-if ( nr_bufs > MAX_NR_BUFS )
+if ( nr_bufs > ARRAY_SIZE(args.buf) )
 return -E2BIG;
 
-if ( copy_from_guest_offset(nat, bufs, 0, nr_bufs) )
+args.domid = domid;
+args.nr_bufs = nr_bufs;
+
+if ( copy_from_guest_offset(&args.buf[0], bufs, 0, args.nr_bufs) )
 return -EFAULT;
 
-rc = dm_op(domid, nr_bufs, nat);
+rc = dm_op(&args);
 
 if ( rc == -ERESTART )
 rc = hypercall_create_continuation(__HYPERVISOR_dm_op, "iih",
-- 
2.1.4


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

[Xen-devel] [PATCH 3/4] hvm/dmop: Implement copy_{to, from}_guest_buf_offset() helpers

[jennifer.herbert]

From: Jennifer Herbert 

copy_{to,from}_guest_buf() are now implemented using an offset of 0.

Signed-off-by: Andrew Cooper 
Signed-off-by: Jennifer Herbert 
--
CC: Paul Durrant 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Julien Grall 
---
 xen/arch/x86/hvm/dm.c | 48 +---
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 3607ddb..6990725 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -32,10 +32,11 @@ struct dmop_args {
 struct xen_dm_op_buf buf[2];
 };
 
-static bool _raw_copy_from_guest_buf(void *dst,
- const struct dmop_args *args,
- unsigned int buf_idx,
- size_t dst_bytes)
+static bool _raw_copy_from_guest_buf_offset(void *dst,
+const struct dmop_args *args,
+unsigned int buf_idx,
+size_t offset_bytes,
+size_t dst_bytes)
 {
 size_t buf_bytes;
 
@@ -44,15 +45,20 @@ static bool _raw_copy_from_guest_buf(void *dst,
 
 buf_bytes =  args->buf[buf_idx].size;
 
-if ( dst_bytes > buf_bytes )
+if ( offset_bytes >= buf_bytes ||
+ (offset_bytes + dst_bytes) < offset_bytes ||
+ (offset_bytes + dst_bytes) > buf_bytes )
 return false;
 
-return !copy_from_guest(dst, args->buf[buf_idx].h, buf_bytes);
+return !copy_from_guest_offset(dst, args->buf[buf_idx].h,
+   offset_bytes, dst_bytes);
 }
 
-static bool _raw_copy_to_guest_buf(struct dmop_args *args,
-   unsigned int buf_idx,
-   const void *src, size_t src_bytes)
+static bool _raw_copy_to_guest_buf_offset(struct dmop_args *args,
+  unsigned int buf_idx,
+  size_t offset_bytes,
+  const void *src,
+  size_t src_bytes)
 {
 size_t buf_bytes;
 
@@ -61,17 +67,29 @@ static bool _raw_copy_to_guest_buf(struct dmop_args *args,
 
 buf_bytes = args->buf[buf_idx].size;
 
-if ( src_bytes > buf_bytes )
+
+if ( offset_bytes >= buf_bytes ||
+ (offset_bytes + src_bytes) < offset_bytes ||
+ (offset_bytes + src_bytes) > buf_bytes )
 return false;
 
-return !copy_to_guest(args->buf[buf_idx].h, src, buf_bytes);
+return !copy_to_guest_offset(args->buf[buf_idx].h, offset_bytes,
+ src, src_bytes);
 }
 
-#define copy_from_guest_buf(dst, args, buf_idx) \
-_raw_copy_from_guest_buf(dst, args, buf_idx, sizeof(*(dst)))
+#define copy_from_guest_buf_offset(dst, bufs, buf_idx, offset_bytes) \
+_raw_copy_from_guest_buf_offset(dst, bufs, buf_idx, offset_bytes, \
+sizeof(*(dst)))
+
+#define copy_to_guest_buf_offset(bufs, buf_idx, offset_bytes, src) \
+_raw_copy_to_guest_buf_offset(bufs, buf_idx, offset_bytes, \
+  src, sizeof(*(src)))
+
+#define copy_from_guest_buf(dst, bufs, buf_idx) \
+copy_from_guest_buf_offset(dst, bufs, buf_idx, 0)
 
-#define copy_to_guest_buf(args, buf_idx, src) \
-_raw_copy_to_guest_buf(args, buf_idx, src, sizeof(*(src)))
+#define copy_to_guest_buf(bufs, buf_idx, src) \
+copy_to_guest_buf_offset(bufs, buf_idx, 0, src)
 
 static int track_dirty_vram(struct domain *d, xen_pfn_t first_pfn,
 unsigned int nr, struct xen_dm_op_buf *buf)
-- 
2.1.4


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

[Xen-devel] [PATCH 4/4] dmop: Add xendevicemodel_modified_memory_bulk()

[jennifer.herbert]

From: Jennifer Herbert 

This new lib devicemodel call allows multiple extents of pages to be
marked as modified in a single call.  This is something needed for a
usecase I'm working on.

The xen side of the modified_memory call has been modified to accept
an array of extents.  The devicemodel library either provides an array
of length 1, to support the original library function, or a second
function allows an array to be provided.

Signed-off-by: Jennifer Herbert 
--
CC: Jan Beulich 
CC: Paul Durrant 
CC: Andrew Cooper 
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 tools/libs/devicemodel/core.c   |  30 --
 tools/libs/devicemodel/include/xendevicemodel.h |  19 +++-
 xen/arch/x86/hvm/dm.c   | 117 
 xen/include/public/hvm/dm_op.h  |  19 +++-
 4 files changed, 134 insertions(+), 51 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index ff09819..d7c6476 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -459,22 +459,36 @@ int xendevicemodel_track_dirty_vram(
  dirty_bitmap, (size_t)(nr + 7) / 8);
 }
 
-int xendevicemodel_modified_memory(
-xendevicemodel_handle *dmod, domid_t domid, uint64_t first_pfn,
-uint32_t nr)
+int xendevicemodel_modified_memory_bulk(
+xendevicemodel_handle *dmod, domid_t domid,
+struct xen_dm_op_modified_memory_extent *extents, uint32_t nr)
 {
 struct xen_dm_op op;
-struct xen_dm_op_modified_memory *data;
+struct xen_dm_op_modified_memory *header;
+size_t extents_size = nr * sizeof(struct xen_dm_op_modified_memory_extent);
 
 memset(&op, 0, sizeof(op));
 
 op.op = XEN_DMOP_modified_memory;
-data = &op.u.modified_memory;
+header = &op.u.modified_memory;
 
-data->first_pfn = first_pfn;
-data->nr = nr;
+header->nr_extents = nr;
+header->opaque = 0;
 
-return xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
+return xendevicemodel_op(dmod, domid, 2, &op, sizeof(op),
+ extents, extents_size);
+}
+
+int xendevicemodel_modified_memory(
+xendevicemodel_handle *dmod, domid_t domid, uint64_t first_pfn,
+uint32_t nr)
+{
+struct xen_dm_op_modified_memory_extent extent;
+
+extent.first_pfn = first_pfn;
+extent.nr = nr;
+
+return xendevicemodel_modified_memory_bulk(dmod, domid, &extent, 1);
 }
 
 int xendevicemodel_set_mem_type(
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 1da216f..580fad2 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -254,8 +254,8 @@ int xendevicemodel_track_dirty_vram(
 uint32_t nr, unsigned long *dirty_bitmap);
 
 /**
- * This function notifies the hypervisor that a set of domain pages
- * have been modified.
+ * This function notifies the hypervisor that a set of contiguous
+ * domain pages have been modified.
  *
  * @parm dmod a handle to an open devicemodel interface.
  * @parm domid the domain id to be serviced
@@ -268,6 +268,21 @@ int xendevicemodel_modified_memory(
 uint32_t nr);
 
 /**
+ * This function notifies the hypervisor that a set of discontiguous
+ * domain pages have been modified.
+ *
+ * @parm dmod a handle to an open devicemodel interface.
+ * @parm domid the domain id to be serviced
+ * @parm extents an array of extent structs, which each hold
+ a start_pfn and nr (number of pfns).
+ * @parm nr the number of extents in the array
+ * @return 0 on success, -1 on failure.
+ */
+int xendevicemodel_modified_memory_bulk(
+xendevicemodel_handle *dmod, domid_t domid,
+struct xen_dm_op_modified_memory_extent extents[], uint32_t nr);
+
+/**
  * This function notifies the hypervisor that a set of domain pages
  * are to be treated in a specific way. (See the definition of
  * hvmmem_type_t).
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 6990725..61df3cf 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -155,56 +155,102 @@ static int set_isa_irq_level(struct domain *d, uint8_t 
isa_irq,
 }
 
 static int modified_memory(struct domain *d,
-   struct xen_dm_op_modified_memory *data)
+   struct dmop_args *bufs,
+   struct xen_dm_op_modified_memory *header)
 {
-xen_pfn_t last_pfn = data->first_pfn + data->nr - 1;
-unsigned int iter = 0;
-int rc = 0;
+#define EXTENTS_BUFFER 1
 
-if ( (data->first_pfn > last_pfn) ||
- (last_pfn > domain_get_maximum_gpfn(d)) )
-return -EINVAL;
+/* Process maximum of 256 pfns before checking for continuation. */
+const unsigned int cont_check_interval = 0x100;
+unsigned int *rem_extents =  &header->nr_extents;
+unsigned int batch_rem_pfns = cont_check_interval;
+/* Used for continuation. */
+unsigned int 

[Xen-devel] [PATCH 2/4] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

[jennifer.herbert]

From: Jennifer Herbert 

This also allows the usual cases to be simplified, by omitting an unnecessary
buf parameters, and because the macros can appropriately size the object.

This makes copying to or from a buf that isn't big enough an error.
If the buffer isnt big enough, trying to carry on regardless
can only cause trouble later on.

Signed-off-by: Andrew Cooper 
Signed-off-by: Jennifer Herbert 
--
CC: Paul Durrant 
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Julien Grall 
---
 xen/arch/x86/hvm/dm.c | 47 +--
 1 file changed, 29 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index fb4bcec..3607ddb 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -32,36 +32,47 @@ struct dmop_args {
 struct xen_dm_op_buf buf[2];
 };
 
-static bool copy_buf_from_guest(const xen_dm_op_buf_t bufs[],
-unsigned int nr_bufs, void *dst,
-unsigned int idx, size_t dst_size)
+static bool _raw_copy_from_guest_buf(void *dst,
+ const struct dmop_args *args,
+ unsigned int buf_idx,
+ size_t dst_bytes)
 {
-size_t size;
+size_t buf_bytes;
 
-if ( idx >= nr_bufs )
+if ( buf_idx >= args->nr_bufs )
 return false;
 
-memset(dst, 0, dst_size);
+buf_bytes =  args->buf[buf_idx].size;
 
-size = min_t(size_t, dst_size, bufs[idx].size);
+if ( dst_bytes > buf_bytes )
+return false;
 
-return !copy_from_guest(dst, bufs[idx].h, size);
+return !copy_from_guest(dst, args->buf[buf_idx].h, buf_bytes);
 }
 
-static bool copy_buf_to_guest(const xen_dm_op_buf_t bufs[],
-  unsigned int nr_bufs, unsigned int idx,
-  const void *src, size_t src_size)
+static bool _raw_copy_to_guest_buf(struct dmop_args *args,
+   unsigned int buf_idx,
+   const void *src, size_t src_bytes)
 {
-size_t size;
+size_t buf_bytes;
 
-if ( idx >= nr_bufs )
+if ( buf_idx >= args->nr_bufs )
 return false;
 
-size = min_t(size_t, bufs[idx].size, src_size);
+buf_bytes = args->buf[buf_idx].size;
+
+if ( src_bytes > buf_bytes )
+return false;
 
-return !copy_to_guest(bufs[idx].h, src, size);
+return !copy_to_guest(args->buf[buf_idx].h, src, buf_bytes);
 }
 
+#define copy_from_guest_buf(dst, args, buf_idx) \
+_raw_copy_from_guest_buf(dst, args, buf_idx, sizeof(*(dst)))
+
+#define copy_to_guest_buf(args, buf_idx, src) \
+_raw_copy_to_guest_buf(args, buf_idx, src, sizeof(*(src)))
+
 static int track_dirty_vram(struct domain *d, xen_pfn_t first_pfn,
 unsigned int nr, struct xen_dm_op_buf *buf)
 {
@@ -312,7 +323,7 @@ static int dm_op(struct dmop_args *op_args)
 if ( rc )
 goto out;
 
-if ( !copy_buf_from_guest(&op_args->buf[0], op_args->nr_bufs, &op, 0, 
sizeof(op)) )
+if ( !copy_from_guest_buf(&op, op_args, 0) );
 {
 rc = -EFAULT;
 goto out;
@@ -568,8 +579,8 @@ static int dm_op(struct dmop_args *op_args)
 }
 
 if ( (!rc || rc == -ERESTART) &&
- !const_op &&
- !copy_buf_to_guest(&op_args->buf[0], op_args->nr_bufs, 0, &op, 
sizeof(op)) )
+ !const_op && !copy_to_guest_buf(op_args, 0, &op) )
+
 rc = -EFAULT;
 
  out:
-- 
2.1.4


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

[Xen-devel] [PATCH] Fix hypervisor crash when writing to VPMU MSR

[Mohit Gambhir]

In order to address the concerns raised in XSA-163, I am writing XTF based
tests to validate PMU MSR read/writes from HVM guests. 

While testing, I found a scenario where setting the Pin Control Flag bit (19) 
of IA32_PERF_EVTSELx results in a General Protection Fault followed by a
hypervisor crash. While Intel SDM Vol 3B, Section 18.2.1.1 Architectural 
Performance Monitoring Version 1 Facilities, describes the bit functionality, 
it is unclear why the fault happens. 

There are two possible solutions to prevent the hypervisor from crashing:

1. Mask the PC bit in the VPMU so as to not allow any writes to it from guests
on any Intel machine. 

2. Use wrmsr_safe() function to write to IA32_PERF_EVTSELx register and return
any resulting fault to the guest OS.

The attached patch uses solution 2 so as to not disable PC flag bit on machines
that do not fault. 

Mohit Gambhir (1):
  x86/vpmu_intel: Fix hypervisor crash by catching wrmsr fault

 xen/arch/x86/cpu/vpmu_intel.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

-- 
2.9.3


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

[Xen-devel] [PATCH] x86/vpmu_intel: Fix hypervisor crash by catching wrmsr fault

[Mohit Gambhir]

This patch changes wrmsrl() calls to write to MSR_P6_EVTSEL register in the
VPMU to wrmsr_safe(). There are known (and possibly some unknown) cases where
setting certain bits in MSR_P6_EVTSEL reg. can cause a General Protection
fault on some machines. Unless we catch this fault when it happens, it will
result in a hypervisor crash.

For instance, setting Pin Control (PC) bit (19) in MSR_P6_EVNTSEL results
in a General Protection Fault on Broadwell machines and thus causes the
hypervisor to crash.

This patch fixes the above mentioned crash (and other possible
hypervisor crashes that may occur while writing MSR_P6_EVNTSEL reg) by
catching and returning the fault to the guest OS.

Signed-off-by: Mohit Gambhir 
---
 xen/arch/x86/cpu/vpmu_intel.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 3f0322c..13808b5 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -338,7 +338,7 @@ static int core2_vpmu_save(struct vcpu *v, bool_t to_guest)
 return 1;
 }
 
-static inline void __core2_vpmu_load(struct vcpu *v)
+static inline int __core2_vpmu_load(struct vcpu *v)
 {
 unsigned int i, pmc_start;
 struct xen_pmu_intel_ctxt *core2_vpmu_cxt = vcpu_vpmu(v)->context;
@@ -356,7 +356,9 @@ static inline void __core2_vpmu_load(struct vcpu *v)
 for ( i = 0; i < arch_pmc_cnt; i++ )
 {
 wrmsrl(pmc_start + i, xen_pmu_cntr_pair[i].counter);
-wrmsrl(MSR_P6_EVNTSEL(i), xen_pmu_cntr_pair[i].control);
+if ( wrmsr_safe(MSR_P6_EVNTSEL(i), xen_pmu_cntr_pair[i].control) ==
+-EFAULT)
+return -EFAULT;
 }
 
 wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
@@ -369,6 +371,7 @@ static inline void __core2_vpmu_load(struct vcpu *v)
 core2_vpmu_cxt->global_ovf_ctrl = 0;
 wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 }
+return 0;
 }
 
 static int core2_vpmu_verify(struct vcpu *v)
@@ -461,9 +464,8 @@ static int core2_vpmu_load(struct vcpu *v, bool_t 
from_guest)
 
 vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 
-__core2_vpmu_load(v);
+return __core2_vpmu_load(v);
 
-return 0;
 }
 
 static int core2_vpmu_alloc_resource(struct vcpu *v)
@@ -538,7 +540,8 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int 
*type, int *index)
 /* Do the lazy load staff. */
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
 {
-__core2_vpmu_load(current);
+if ( __core2_vpmu_load(current) )
+return 0;
 vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 if ( is_hvm_vcpu(current) &&
  cpu_has_vmx_msr_bitmap )
@@ -719,8 +722,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 }
 }
 
-if ( type != MSR_TYPE_GLOBAL )
-wrmsrl(msr, msr_content);
+if ( type != MSR_TYPE_GLOBAL)
+{
+if ( wrmsr_safe(msr, msr_content) == -EFAULT )
+return -EFAULT;
+}
 else
 {
 if ( is_hvm_vcpu(v) )
-- 
2.9.3


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

Re: [Xen-devel] Xen Project Security Team considering becoming a CNA

[Steven Haigh]

On 21/04/17 01:57, Ian Jackson wrote:
> (Resending with the correct CC (!))
> 
> We are in discussions with MITRE with a view to potentially becoming a
> CVE Numbering Authority.  This would probably smooth the process of
> getting CVE numbers for XSAs.
> 
> If anyone has any opinions/representations/concerns/whatever about
> this, please do share them (here in this thread, or privately to
> security@).

YES.

YES. YES. YES. YES. YES. YES. YES. YES. YES. YES. YES. YES. YES. YES.
YES. YES. YES. YES. YES. YES. YES. YES. YES. YES. YES. YES. YES. YES.

Yes.

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



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

[Xen-devel] [PATCH] xen/pvh: Do not fill kernel's e820 map in init_pvh_bootparams()

[Boris Ostrovsky]

e820 map is updated with information from the zeropage (i.e.
pvh_bootparams) by default_machine_specific_memory_setup().
With the way things are done now, we end up with a duplicated
e820 map.

Signed-off-by: Boris Ostrovsky 
---
This patch is against for-linus-4.12 branch. Since this is not
a critical issue I don't want to submit it to 4.11 at rc8 time
(plus it will require rebasing for-linus-4.12).


 arch/x86/xen/enlighten_pvh.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 331d769..7ce319a9 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -33,7 +33,6 @@ static void xen_pvh_arch_setup(void)
 static void __init init_pvh_bootparams(void)
 {
struct xen_memory_map memmap;
-   unsigned int i;
int rc;
 
memset(&pvh_bootparams, 0, sizeof(pvh_bootparams));
@@ -60,12 +59,7 @@ static void __init init_pvh_bootparams(void)
sanitize_e820_map(pvh_bootparams.e820_map,
  ARRAY_SIZE(pvh_bootparams.e820_map),
  &memmap.nr_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;
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v2 for-4.9 0/5] xen/arm: Properly map the FDT in the boot page table

[Stefano Stabellini]

I committed this series, thank you.

On Thu, 20 Apr 2017, Julien Grall wrote:
> Hi,
> 
> Whilst doing some testing on Juno using GRUB, I noticed random early crash
> depending ([1]) on the binaries I was using.
> 
> This is because Xen is assuming that the FDT will always fit in a 2MB
> superpage whilst the boot documentation allow the FDT to cross a 2MB boundary.
> 
> The first patch move the code that map the FDT in the boot page table from
> assembly to C making easier to modify the code.
> 
> This series is candidate for Xen 4.9. Whilst this early boot rework sounds
> scary, a user can see random early crash without this series. I chose
> to move all the FDT mapping code in C right now because it is less error-prone
> to write C code than assembly.
> 
> I have tested both ARM32 and ARM64 with different position of the FDT without
> noticing any issue.
> 
> For all the changes see in each patches.
> 
> Cheers,
> 
> [1]
> 
> (XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
> (XEN) CPU0: Unexpected Trap: Hypervisor
> (XEN) [ Xen-4.9-unstable  arm64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) PC: 00264140 strlen+0x10/0x84
> (XEN) LR: 002401c0
> (XEN) SP: 002cfc20
> (XEN) CPSR:   43c9 MODE:64-bit EL2h (Hypervisor, handler)
> (XEN)  X0: 00801230  X1: 00801230  X2: 5230
> (XEN)  X3: 0030  X4: 0030  X5: 0038
> (XEN)  X6: 0034  X7:   X8: 7f7f7f7f7f7f7f7f
> (XEN)  X9: 64622c6479687222 X10: 7f7f7f7f7f7f7f7f X11: 0101010101010101
> (XEN) X12: 0030 X13: ff00ff00 X14: 08000300
> (XEN) X15:  X16: fefff610 X17: 00f0
> (XEN) X18: 0004 X19: 0008 X20: 007fc040
> (XEN) X21: 007fc000 X22: 000e X23: 
> (XEN) X24: 002a9f58 X25: 00801230 X26: 002a9f68
> (XEN) X27: 002a9f58 X28: 00298910  FP: 002cfc20
> (XEN)
> (XEN)   VTCR_EL2: 80010c40
> (XEN)  VTTBR_EL2: 082800203000
> (XEN)
> (XEN)  SCTLR_EL2: 30c5183d
> (XEN)HCR_EL2: 0038663f
> (XEN)  TTBR0_EL2: f4912000
> (XEN)
> (XEN)ESR_EL2: 9606
> (XEN)  HPFAR_EL2: e8071000
> (XEN)FAR_EL2: 00801230
> (XEN)
> (XEN) Xen stack trace from sp=002cfc20:
> (XEN)002cfc70 00240254 002a9f58 007fc000
> (XEN)   007fc03c
> (XEN)002cfd78  002cfca0 002986fc
> (XEN) 007fc000  
> (XEN)002cfcc0 00298f1c  007fc000
> (XEN)002cfdc0 0029904c f47fc000 f4604000
> (XEN)f47fc000 007fc000 0040 0100
> (XEN)f4604000 0001 0001 8002
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)  002cfdc0 00299038
> (XEN)f47fc000 f4604000 f47fc000 
> (XEN)002cfe20 0029c420 002d8000 f4604000
> (XEN)f47fc000  0040 0100
> (XEN)f4604000 0001 f47fc000 0029c404
> (XEN)fefff510 00200624 f4804000 f4604000
> (XEN)f47fc000  0040 0100
> (XEN)0001 0001 0001 8002
> (XEN)f47fc000   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN) Xen call trace:
> (XEN)[<00264140>] strlen+0x10/0x84 (PC)
> (XEN)[<00240

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Boris Ostrovsky]

On 04/20/2017 12:15 PM, Peter Zijlstra wrote:
> On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote:
>>> This is getting ludicrous. Xen is plain broken, and instead of fixing
>>> it, you propose to somehow deal with its obviously crack induced
>>> behaviour :-(
>> Totally agree and I don't like the solution I propose (and that's why
>> this is RFC)... The problem is that there are such Xen setups in the
>> wild and with the recent changes some guests will BUG() :-(
>>
>> Alternatively, we can just remove the BUG() and do something with CPUs
>> which have their pkg >= __max_logical_packages, e.g. assign them to the
>> last package. Far from ideal but will help to avoid the regression.
> So currently none of the stuff that uses this should appear in Xen. Its
> all drivers for hardware that isn't virtualized (afaik). So assigning to
> the last package 'works'.
>
> But the moment this ends up getting used that explodes, because we'll
> need different object instances for each piece of hardware.


This already gets used. I don't remember details but we had to fix
something due to RAPL code referencing topology info (and yes, there is
no reason for a guest to use RAPL, but we shouldn't crash neither)


>
> There just isn't a good solution; on the one hand the BIOS is prone to
> providing crap numbers, on the other hand virt (esp. Xen as it turns
> out) provides absolutely bonkers/inconsistent topology information.
>
> Very frustrating :-/
>

So we might need a way to bypass topology discovery and present some
sort of default topology (single package, or 1 CPU per package, for
example) and ignore APICID and all that.

-boris

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

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Andrew Cooper]

On 20/04/17 16:06, Peter Zijlstra wrote:
> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>> In this patch I suggest we set __max_logical_packages based on the
>> max_physical_pkg_id and total_cpus,
> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
> instead of 4.
>
> This wastes quite a bit of memory for the per-node arrays. Luckily most
> are just pointer arrays, but still, wasting 140*8 bytes for each of
> them.
>
>> this should be safe and cover all
>> possible cases. Alternatively, we may think about eliminating the concept
>> of __max_logical_packages completely and relying on max_physical_pkg_id/
>> total_cpus where we currently use topology_max_packages().
>>
>> The issue could've been solved in Xen too I guess. CPUID returning
>> x86_max_cores can be tweaked to be the lowerest(?) possible number of
>> all logical packages of the guest.
> This is getting ludicrous. Xen is plain broken, and instead of fixing
> it, you propose to somehow deal with its obviously crack induced
> behaviour :-(

Xen is (and has been forever) plain broken in this specific regard. 
Fixing CPUID handling for guests has taken me 18 months and ~80 patches
so far, and it still isn't complete.

However, Linux needs to be able to function on existing production
systems (which is every instance of Xen currently running).

Linux shouldn't BUG() because something provided by the firmware looks
wonky.  This is conceptually no different from finding junk the APCI tables.

(I fully agree that we shouldn't have got to this state, but we are 12
years too late in this respect.)

~Andrew

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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Lars Kurth]

> On 20 Apr 2017, at 14:21, Jan Beulich  wrote:
> 
 On 20.04.17 at 15:02,  wrote:
>>> On 20 Apr 2017, at 10:43, Jan Beulich  wrote:
>>> 
>> On 20.04.17 at 04:14,  wrote:
 On 17-04-19 03:00:29, Jan Beulich wrote:
 On 19.04.17 at 10:22,  wrote:
>> On 17-04-18 05:46:43, Jan Beulich wrote:
>> On 18.04.17 at 12:55,  wrote:
 I made a test patch based on v10 and attached it in mail. Could you 
 please
 help to check it? Thanks!
>>> 

[Item 1]

>>> This looks reasonable at the first glance, albeit I continue to be
>>> unconvinced that this is the only (reasonable) way of solving the
 
 Do you have any other suggestion on this? Thanks!
>>> 
>>> I'm sorry, but no. I'm already spending _much_ more time on this
>>> series than I should be, considering its (afaic) relatively low
>>> priority. I really have to ask you to properly think through both
>>> the data layout and code structure, including considering
>>> alternatives especially in places where you can _anticipate_
>>> controversy.
>> 
>> Jan, can you confirm whether you are happy with the current proposal. You 
>> say "this looks reasonable at the first glance", but then go on to say that 
>> there may be other "reasonable ways" of solving the problem at hand.
>> 
>> This is not very concrete and hard to respond to from a contributors point 
>> of view: it would be good to establish whether a) the v10 proposal in this 
>> area is good enough, b) whether there are any concrete improvements to be 
>> made.

> I understand it's not very concrete, but please understand that with
> the over 100 patches wanting looking at right now it is simply
> impossible for me to give precise suggestions everywhere. I really
> have to be allowed to defer to the originator to come up with
> possible better mechanisms (or defend what there is by addressing
> questions raised),

Jan, I don't object to the principle of deferring issues to a contributor, for 
contributor to defend their viewpoint or to come up with a better mechanism. I 
just observed, that I could not make a lot of sense what you were looking for 
in this particular review. I am assuming that it would be even harder for Yi. 

> especially with - as said - the amount of time spent
> here already having been way higher than is justifiable.

And of course we have passed the 4.9 code freeze, so some of the pressure is 
off. At the same time I understand that because of the upcoming releases you 
need to focus on bug fixes, etc.

> Just go and
> compare v10 with one of the initial versions: Almost all of the data
> layout and code flow have fundamentally changed, mostly based on
> feedback I gave. I'm sorry for saying that, but to me this is an
> indication that things hadn't been thought through well in the design
> phase, i.e. before even submitting a first RFC.

That is good feedback which may contain some valuable lessons. Once we are 
through this (or maybe at the summit) it may be worthwhile to look at what has 
gone wrong and see how we can do better in future.

[Item 2]

>> You say please think through whether "you can _anticipate_ controversy", but 
>> at the same time you can't currently identify/think of any issues. That 
>> seems 
>> to suggest to me that maybe the proposal is good enough. Or that something 
>> is 
>> missing, which has not been articulated. Taking into account language 
>> barriers, more clarity would probably be helpful.
> 
> I've given criteria by which I have the gut feeling (but no more)
> that this isn't the right approach. I'm absolutely fine to be
> convinced that my gut feeling is wrong. That would require to
> simply answer the question I raised multiple times, and which was
> repeatedly "answered" by simply re-stating previously expressed
> facts.

I have not followed the full thread. But it seems that we have communications 
issue there. Normally this happens when expectations don't quite match and one 
party (in this case Yi) does not quite get what the other one is looking for. 
Maybe the best approach would be for Yi to get some of these things resolved 
during a short IRC conversation with you. I did see him and others resolve some 
previous issues more effectively on IRC. 

> If this reaction of mine is not acceptable, all I can do is refrain
> from further looking at this series. And Yi, I certainly apologize
> for perhaps not doing these reviews wholeheartedly, since -
> as also expressed before - I continue to not really view this as
> very important functionality.

As I said earlier, I stepped in, as I didn't really understand what was going 
on. I think this is a little clearer now. 

So to summarise: 

On item 1: it appears that you are looking for a some more justification why 
some of the changes were made, maybe with a rationale for some of the choices 
that were made. Given that this is quite a complex series which has diverged 
quite a lot from the design, the goal is to make it easier for 

Re: [Xen-devel] [PATCH] x86/mm: also flush TLB when putting writable foreign page reference

[Jann Horn]

On Thu, Apr 20, 2017 at 5:26 PM, Jan Beulich  wrote:
> Jann's explanation of the problem:
>
> "start situation:
>  - domain A and domain B are PV domains
>  - domain A and B both have currently scheduled vCPUs, and the vCPUs
>are not scheduled away
>  - domain A has XSM_TARGET access to domain B
>  - page X is owned by domain B and has no mappings
>  - page X is zeroed
>
>  steps:
>  - domain A uses do_mmu_update() to map page X in domain A as writable
>  - domain A accesses page X through the new PTE, creating a TLB entry
>  - domain A removes its mapping of page X
>- type count of page X goes to 0
>- tlbflush_timestamp of page X is bumped
>  - domain B maps page X as L1 pagetable
>- type of page X changes to PGT_l1_page_table
>- TLB flush is forced using domain_dirty_cpumask of domain B
>- page X is mapped as L1 pagetable in domain B
>
>  At this point, domain B's vCPUs are guaranteed to have no
>  incorrectly-typed stale TLB entries for page X, but AFAICS domain A's
>  vCPUs can still have stale TLB entries that map page X as writable,
>  permitting domain A to control a live pagetable of domain B."
>
> Domain A necessarily is Dom0 (DomU-s with XSM_TARGET permission are
> being created only for HVM domains, but domain B needs to be PV here),
> so this is not a security issue, but nevertheless seems desirable to
> correct.
>
> Reported-by: Jann Horn 
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -602,6 +602,20 @@ static inline void guest_get_eff_kern_l1
>  TOGGLE_MODE();
>  }
>
> +static const cpumask_t *get_flush_tlb_mask(const struct page_info *page,
> +   const struct domain *d)
> +{
> +cpumask_t *mask = this_cpu(scratch_cpumask);
> +
> +BUG_ON(in_irq());
> +cpumask_copy(mask, d->domain_dirty_cpumask);
> +
> +/* Don't flush if the timestamp is old enough */
> +tlbflush_filter(mask, page->tlbflush_timestamp);
> +
> +return mask;
> +}
> +
>  const char __section(".bss.page_aligned.const") __aligned(PAGE_SIZE)
>  zero_page[PAGE_SIZE];
>
> @@ -1266,6 +1280,23 @@ void put_page_from_l1e(l1_pgentry_t l1e,
>  if ( (l1e_get_flags(l1e) & _PAGE_RW) &&
>   ((l1e_owner == pg_owner) || !paging_mode_external(pg_owner)) )
>  {
> +/*
> + * Don't leave stale writable TLB entries in the unmapping domain's
> + * page tables, to prevent them allowing access to pages required to
> + * be read-only (e.g. after pg_owner changed them to page table or
> + * segment descriptor pages).
> + */
> +if ( unlikely(l1e_owner != pg_owner) )
> +{
> +const cpumask_t *mask = get_flush_tlb_mask(page, l1e_owner);
> +
> +if ( !cpumask_empty(mask) )
> +{
> +perfc_incr(need_flush_tlb_flush);
> +flush_tlb_mask(mask);
> +}
> +}

Why does this use a flush masked with page->tlbflush_timestamp?
Shouldn't it force an unconditional flush on the whole domain, similar to
gnttab_flush_tlb()?

Also: I think the same issue might apply to readonly mappings where
the page is released back to the dom heap afterwards. The current fix
only covers writable pages.

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

[Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Julien Grall]

Hi all,

Below the meeting minutes for the previous Xen community call. Feel free to
reply if I missed some parts.

I suggest to have the next call on the 3rd May at 5PM BST. Any opinions.

Also, do you have any specific topic you would like to talk during this 
call?


Cheers,

== Attendees ==

Stefano, Aporeto
Julien, ARM
Oleksandr, EPAM
Volodymir, EPAM
Edgar, Xilinx
Anasatasios, OnApp

== SMC and EL0 App ==

Some SMC call may be sensitive to latency (e.g power down).

Stefano: We would need to be able to decide whether SMC are emulated in 
EL0 or EL2.


Edgar: Shall I wait EL0 App support before resending the series to 
forward SMC on Zynqmp [1]?


Answer: No need to wait, the current approach is fine for now.

Xen EL0 update from Volodymir:
* Thread started on xen-devel (see [2])
* Stefano suggested to create and share a small example
* Plan -> Post the patches on github + writing document

== IOMMU ==

Xen does not support the generic IOMMU bindings.

ACTION: Needs to be fixed ASAP. Potentially on Xen 4.9?

== Reserve region support in DT ==

Reserve region is not mapped in DOM0, though they should be mapped. DMA 
API will allocate memory for those regions.


There was a discussion about that few months ago (see [3]). This would 
need to be followed-up.


== Cross-compiling ==

Anastasios: We are looking at support Xen in Buildroot. The use case is 
a small initramfs.


Potential task: Keep Xen updated on buildroot. Anastasios could help on 
that.


Stefano: Xen is compiling fine with Yocto.

ACTION: Stefano to write a wiki page about using meta-virtualization on 
Yocto.


Release update
--

Stefano might keep a branch around to keep patches which target the next
release.

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg00634.html
[2] 
https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01002.html

[3] https://lists.xen.org/archives/html/xen-devel/2016-11/msg02295.html

--
Julien Grall

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

Re: [Xen-devel] superpages lost after migration of HVM domU

[Jan Beulich]

>>> On 20.04.17 at 18:04,  wrote:
> On Thu, Apr 20, Andrew Cooper wrote:
> 
>> As it currently stands, the sending side iterates from 0 to p2m_size,
>> and sends every frame on the first pass.  This means we get PAGE_DATA
>> records linearly, in batches of 1024, or two aligned 2M superpages.
> 
> Is there a way to preserve 1G pages? This 380G domU I'm looking at is
> built with 4k:461390 2M:2341 1G:365 pages.

I think we've hashed out a possible way to deal with this, by
speculatively allocating 1G pages as long as the allocation cap for
the domain allows, subsequently punching holes into those pages
if we can't allocate any new pages anymore (due to otherwise
overrunning the cap). For ballooned down guests this may add
some unnecessary overhead during migration, but I think the
post-migration benefit outweighs this. All that would be needed
is a second bitmap paralleling the one tracking populated pages,
to also track which pages we've actually seen data for (as those
obviously aren't candidates for the hole punching).

Jan


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

Re: [Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Chao Gao]

On Thu, Apr 20, 2017 at 04:39:06PM +0100, Julien Grall wrote:
>Hi,
>
>On 20/04/17 14:34, Jan Beulich wrote:
>> > > > On 19.04.17 at 22:22,  wrote:
>> > According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>> > "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>> > and APIC ID are preserved when handling INIT signal and a reset places
>> > APIC to xAPIC mode and APIC base address to 0xFEE0h (this part
>> > is in "Local APIC" -> "Local APIC Status and Location"). So there are
>> > two problems in current code:
>> > 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>> > 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>> > 
>> > This patch introduces a new function vlapic_do_init() and replaces the
>> > wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>> > in vlapic_reset().
>> > 
>> > Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>> > mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>> > signal in x2APIC mode.
>> > 
>> > Signed-off-by: Chao Gao 
>> 
>> Reviewed-by: Jan Beulich 
>> 
>> > I regard this patch as a bug fix. But I haven't seen issues caused by
>> > this bug and am not sure of the existance of such issues. Anyhow Cc
>> > Julien and leave the decision to you (Julien and Jan).
>> 
>> Julien,
>> 
>> I'm slightly in favor of taking it now, but I won't object if you decide
>> otherwise.
>
>Chao, can you assess the benefits/risks of having this patch in Xen 4.9?

I think the risk is low for only fixing SPEC mismatched behavior and
benefit is also small as cases (changing APIC ID or Performance INIT
operation) trigger this bug are rare.

Thanks
Chao

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

[Xen-devel] [libvirt test] 107556: tolerable FAIL - PUSHED

[osstest service owner]

flight 107556 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107556/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107536
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107536
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107536

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  dd81f56842350a8d64c53bfa8a09dc9f35a91f7e
baseline version:
 libvirt  bd13b26da25bd33ca3d8885448df76e5b3eecf6a

Last test of basis   107536  2017-04-19 04:21:01 Z1 days
Testing same since   107556  2017-04-20 04:20:58 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Jiri Denemark 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsfail
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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=libvirt
+ revision=dd81f56842350a8d64c53bfa8a09dc9f35a91f7e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Vitaly Kuznetsov]

Boris Ostrovsky  writes:

> On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote:
>> Peter Zijlstra  writes:
>>
>>> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
 In this patch I suggest we set __max_logical_packages based on the
 max_physical_pkg_id and total_cpus,
>>> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
>>> instead of 4.
>>>
>>> This wastes quite a bit of memory for the per-node arrays. Luckily most
>>> are just pointer arrays, but still, wasting 140*8 bytes for each of
>>> them.
>>>
 this should be safe and cover all
 possible cases. Alternatively, we may think about eliminating the concept
 of __max_logical_packages completely and relying on max_physical_pkg_id/
 total_cpus where we currently use topology_max_packages().

 The issue could've been solved in Xen too I guess. CPUID returning
 x86_max_cores can be tweaked to be the lowerest(?) possible number of
 all logical packages of the guest.
>>> This is getting ludicrous. Xen is plain broken, and instead of fixing
>>> it, you propose to somehow deal with its obviously crack induced
>>> behaviour :-(
>> Totally agree and I don't like the solution I propose (and that's why
>> this is RFC)... The problem is that there are such Xen setups in the
>> wild and with the recent changes some guests will BUG() :-(
>>
>> Alternatively, we can just remove the BUG() and do something with CPUs
>> which have their pkg >= __max_logical_packages, e.g. assign them to the
>> last package. Far from ideal but will help to avoid the regression.
>
> Do you observe this failure on PV or HVM guest?
>
> We've had a number of issues with topology discovery for PV guests but
> AFAIK they have been addressed (so far). I wonder though whether it
> would make sense to have some sort of a callback (or an smp_ops.op) to
> override native topology info, if needed.
>

This is HVM.

I guess that CPUID handling for AMD processors in the hypervisor doesn't
adjust the core information and passes it from hardware as-is while it
should be tweaked.

-- 
  Vitaly

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Markus Armbruster]

Eric Blake  writes:

> On 04/20/2017 06:59 AM, Markus Armbruster wrote:
>
>> 
>> No objection to Alistair's idea to turn this into an enumeration.
>
> Question - should the enum be more than just 'guest' and 'host'?  For
> example, my patch proves that we have a lot of places that handle
> complimentary machine commands to reset and shutdown, and that whether
> 'reset' triggers a reset (and the guest keeps running as if rebooted) or
> a shutdown is then based on the command-line arguments given to qemu.
> So having the enum differentiate between 'guest-reset' and
> 'guest-shutdown' would be a possibility, if we want the enum to have
> additional states.

I don't know.  What I do know is that we better get the enum right:
while adding members is backwards-compatible, changing the member sent
for a specific trigger is not.  If we want to reserve the option to do
that anyway, we need suitable documentation.

>>> +++ b/vl.c
>>> @@ -1717,7 +1717,7 @@ void qemu_system_guest_panicked(GuestPanicInformation 
>>> *info)
>>>  if (!no_shutdown) {
>>>  qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_POWEROFF,
>>> !!info, info, &error_abort);
>>> -qemu_system_shutdown_request();
>>> +qemu_system_shutdown_request(false);
>> 
>> Panicking is a guest action.  Whether the shutdown on panic should be
>> attributed to guest or host is perhaps debatable.
>
> And it relates to the idea that a guest request for a 'reset' turns into
> a qemu response of 'shutdown'.  After all, whether a guest panic results
> in a shutdown action is determined by command-line arguments to qemu.
> So if we DO want to differentiate between a guest panic and a normal
> guest shutdown, when both events are wired at the command line to cause
> the SHUTDOWN action, then that's another enum to add to my list.
>
>
>>> +++ b/replay/replay.c
>>> @@ -51,7 +51,10 @@ bool replay_next_event_is(int event)
>>>  switch (replay_state.data_kind) {
>>>  case EVENT_SHUTDOWN:
>>>  replay_finish_event();
>>> -qemu_system_shutdown_request();
>>> +/* TODO: track source of shutdown request, to replay a
>>> + * guest-initiated request rather than always claiming to
>>> + * be from the host? */
>>> +qemu_system_shutdown_request(false);
>> 
>> This is what your "need a followup patch" refers to.  I'd like to have
>> an opinion from someone familiar with replay on what exactly we need
>> here.
>
> replay-internal.h has an enum ReplayEvents, which is a list of one-byte
> codes used in the replay data stream to record which event to replay. I
> don't know if it is easier to change the replay stream to add a 2-byte
> code (shutdown-with-cause, followed by an encoding of the cause enum),
> or a range of one-byte codes (one new code per number of enum members).
> I also don't know how easy or hard it is to extend the enum (are we free
> to add events in the middle, or are we worried about back-compat to an
> older replay stream that must still play correctly with a newer qemu,
> such that new events must be higher than all existing events).
>
> So yes, I'm hoping for feedback from someone familiar with replay.
>
>> 
>> Amazing number of ways to shut down or reset a machine.
>
> And as I said, it would be easier to submit a patch with less churn by
> having the uncommon case (host-triggered) call a new
> qemu_system_shutdown_request_reason(enum), while the common case
> (guest-triggered) be handled by having qemu_system_shutdown_request()
> with no arguments call
> qemu_system_shutdown_request_reason(SHUTDOWN_GUEST).  I'm just worried
> that doing it that way makes it easy for yet another new host shutdown
> method to use the wrong wrapper.

I don't mind the churn.  It does simplify review.

>> Looks sane on first glance.
>> 

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

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Peter Zijlstra]

On Thu, Apr 20, 2017 at 05:40:37PM +0200, Vitaly Kuznetsov wrote:
> > This is getting ludicrous. Xen is plain broken, and instead of fixing
> > it, you propose to somehow deal with its obviously crack induced
> > behaviour :-(
> 
> Totally agree and I don't like the solution I propose (and that's why
> this is RFC)... The problem is that there are such Xen setups in the
> wild and with the recent changes some guests will BUG() :-(
> 
> Alternatively, we can just remove the BUG() and do something with CPUs
> which have their pkg >= __max_logical_packages, e.g. assign them to the
> last package. Far from ideal but will help to avoid the regression.

So currently none of the stuff that uses this should appear in Xen. Its
all drivers for hardware that isn't virtualized (afaik). So assigning to
the last package 'works'.

But the moment this ends up getting used that explodes, because we'll
need different object instances for each piece of hardware.

There just isn't a good solution; on the one hand the BIOS is prone to
providing crap numbers, on the other hand virt (esp. Xen as it turns
out) provides absolutely bonkers/inconsistent topology information.

Very frustrating :-/

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

Re: [Xen-devel] [RFC PATCH v2 05/25] x86: NUMA: Move generic dummy_numa_init to separate function

[Julien Grall]

Hi Vijay,

On 28/03/17 16:53, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

Split numa_initmem_init() so that the numa fallback code is moved
as separate function which is generic.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/x86/numa.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 6b794a7..0888d53 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -268,21 +268,10 @@ static int __init numa_emulation(uint64_t start_pfn, 
uint64_t end_pfn)
 }
 #endif

-void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
+static void __init numa_dummy_init(unsigned long start_pfn, unsigned long 
end_pfn)
 {
 int i;

-#ifdef CONFIG_NUMA_EMU
-if ( get_numa_fake() && !numa_emulation(start_pfn, end_pfn) )
-return;
-#endif
-
-#ifdef CONFIG_ACPI_NUMA
-if ( !is_numa_off() && !acpi_scan_nodes((uint64_t)start_pfn << PAGE_SHIFT,
- (uint64_t)end_pfn << PAGE_SHIFT) )
-return;
-#endif
-
 printk(KERN_INFO "%s\n",
is_numa_off() ? "NUMA turned off" : "No NUMA configuration found");

@@ -301,6 +290,22 @@ void __init numa_initmem_init(unsigned long start_pfn, 
unsigned long end_pfn)
 (paddr_t)end_pfn << PAGE_SHIFT);
 }

+void __init numa_initmem_init(unsigned long start_pfn, unsigned long end_pfn)
+{
+#ifdef CONFIG_NUMA_EMU
+if ( get_numa_fake() && !numa_emulation(start_pfn, end_pfn) )
+return;
+#endif


I am not sure where to comment about it in this series, so I will say it 
here.


As asked on v1, why don't you consider fake NUMA? This would help to 
test the series on non-NUMA platform.



+
+#ifdef CONFIG_ACPI_NUMA
+if ( !is_numa_off() && !acpi_scan_nodes((uint64_t)start_pfn << PAGE_SHIFT,
+ (uint64_t)end_pfn << PAGE_SHIFT) )
+return;
+#endif
+
+numa_dummy_init(start_pfn, end_pfn);
+}
+
 void numa_add_cpu(int cpu)
 {
 cpumask_set_cpu(cpu, &node_to_cpumask[cpu_to_node(cpu)]);



Cheers,

--
 Julien Grall

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Markus Armbruster]

Eric Blake  writes:

> On 04/20/2017 07:09 AM, Daniel P. Berrange wrote:
>
 +++ b/qapi/event.json
 @@ -10,6 +10,10 @@
  # Emitted when the virtual machine has shut down, indicating that qemu is
  # about to exit.
  #
 +# @guest: If true, the shutdown was triggered by a guest request (such as
 +# executing a halt instruction) rather than a host request (such as 
 sending
 +# qemu a SIGINT). (since 2.10)
 +#
>>>
>>> "executing a halt instruction" suggests "halt" is a machine instruction.
>
> Which is indeed what most of the places I patched to pass 'true' are
> emulating - the machine halt instruction.
>
>>> I think you mean /usr/sbin/halt.  Suggest something like "executing a
>>> halt command".
>> 
>> Well technically /usr/sbin/halt just terminates all processes / kernel and
>> halts CPUs, but the virtual machine is still active (and a 'reset' in the
>> monitor can start it again. /usr/sbin/poweroff is what actually does the
>> ACPI poweroff to trigger QEMU to exit[1]
>
> I'm thinking of this wording:
>
> triggered by a guest request (such as the guest running
> /usr/sbin/poweroff to trigger an ACPI shutdown or machine halt instruction)

A quick glance at the patch suggests the instructions in question are
typically writes to some device register.  I wouldn't call them "halt
instructions", in particular since there's the x86 "hlt" instruction
that does something else.

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

[Xen-devel] [linux-3.18 baseline-only test] 71209: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71209 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71209/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-midway   15 guest-start/debian.repeat fail REGR. vs. 68537
 test-amd64-i386-xl-qemuu-debianhvm-amd64 20 leak-check/check fail REGR. vs. 
68537

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68537
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68537
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 68537
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68537
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 68537
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68537
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68537

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   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-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-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linuxe6ff2eed0d0865fd3b0391b7e88ecc5e259eed28
baseline version:
 linux53752ea210016b548cfc3898e6a5ea338fcb6c2c

Last test of basis68537  2017-02-08 15:20:08 Z   71 days
Testing same since71209  2017-04-20 08:20:26 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alexander Popov 
  Alexander Potapenko 
  Alexei Starovoitov 
  Andrew Collins 
  Andrew Morton 
  Andrey Konovalov 
  Andrey Ryabinin 

Re: [Xen-devel] superpages lost after migration of HVM domU

[Olaf Hering]

On Thu, Apr 20, Andrew Cooper wrote:

> As it currently stands, the sending side iterates from 0 to p2m_size,
> and sends every frame on the first pass.  This means we get PAGE_DATA
> records linearly, in batches of 1024, or two aligned 2M superpages.

Is there a way to preserve 1G pages? This 380G domU I'm looking at is
built with 4k:461390 2M:2341 1G:365 pages.

Was there any performance testing done with the new code? I think the
15-20% degradion we are seeing might be caused by this.


Olaf


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

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Boris Ostrovsky]

On 04/20/2017 11:40 AM, Vitaly Kuznetsov wrote:
> Peter Zijlstra  writes:
>
>> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>>> In this patch I suggest we set __max_logical_packages based on the
>>> max_physical_pkg_id and total_cpus,
>> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
>> instead of 4.
>>
>> This wastes quite a bit of memory for the per-node arrays. Luckily most
>> are just pointer arrays, but still, wasting 140*8 bytes for each of
>> them.
>>
>>> this should be safe and cover all
>>> possible cases. Alternatively, we may think about eliminating the concept
>>> of __max_logical_packages completely and relying on max_physical_pkg_id/
>>> total_cpus where we currently use topology_max_packages().
>>>
>>> The issue could've been solved in Xen too I guess. CPUID returning
>>> x86_max_cores can be tweaked to be the lowerest(?) possible number of
>>> all logical packages of the guest.
>> This is getting ludicrous. Xen is plain broken, and instead of fixing
>> it, you propose to somehow deal with its obviously crack induced
>> behaviour :-(
> Totally agree and I don't like the solution I propose (and that's why
> this is RFC)... The problem is that there are such Xen setups in the
> wild and with the recent changes some guests will BUG() :-(
>
> Alternatively, we can just remove the BUG() and do something with CPUs
> which have their pkg >= __max_logical_packages, e.g. assign them to the
> last package. Far from ideal but will help to avoid the regression.

Do you observe this failure on PV or HVM guest?

We've had a number of issues with topology discovery for PV guests but
AFAIK they have been addressed (so far). I wonder though whether it
would make sense to have some sort of a callback (or an smp_ops.op) to
override native topology info, if needed.

-boris


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

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

[Julien Grall]

Hi Vijay,

On 28/03/17 16:53, vijay.kil...@gmail.com wrote:

From: Vijaya Kumar K 

Add accessor functions for acpi_numa and numa_off static
variables. Init value of acpi_numa is set 1 instead of 0.


Please explain why you change the acpi_numa value from 0 to 1.

Also, I am not sure to understand the benefits of those helpers. Why do 
you need them? Why not using the global variable directly, this will 
avoid to call a function just for returning a value...



Also return value of srat_disabled is changed to bool.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/x86/numa.c| 43 +++
 xen/arch/x86/setup.c   |  2 +-
 xen/arch/x86/srat.c| 12 ++--
 xen/include/asm-x86/acpi.h |  1 -
 xen/include/asm-x86/numa.h |  5 +
 xen/include/xen/numa.h |  3 +++
 6 files changed, 42 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 964fc5a..6b794a7 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -42,12 +42,27 @@ cpumask_t __read_mostly node_to_cpumask[MAX_NUMNODES];

 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };

-bool numa_off = 0;
-s8 acpi_numa = 0;
+static bool numa_off = 0;
+static bool acpi_numa = 1;


Please don't mix 0/1 and bool. Instead use false/true.



-int srat_disabled(void)
+bool is_numa_off(void)
 {
-return numa_off || acpi_numa < 0;
+return numa_off;
+}
+
+bool get_acpi_numa(void)
+{
+return acpi_numa;
+}
+
+void set_acpi_numa(bool_t val)
+{
+acpi_numa = val;
+}
+
+bool srat_disabled(void)
+{
+return numa_off || acpi_numa == 0;
 }

 /*
@@ -202,13 +217,17 @@ void __init numa_init_array(void)

 #ifdef CONFIG_NUMA_EMU
 static int __initdata numa_fake = 0;
+static int get_numa_fake(void)
+{
+return numa_fake;
+}

 /* Numa emulation */
 static int __init numa_emulation(uint64_t start_pfn, uint64_t end_pfn)
 {
 int i;
 struct node nodes[MAX_NUMNODES];
-uint64_t sz = ((end_pfn - start_pfn) << PAGE_SHIFT) / numa_fake;
+uint64_t sz = ((end_pfn - start_pfn) << PAGE_SHIFT) / get_numa_fake();

 /* Kludge needed for the hash function */
 if ( hweight64(sz) > 1 )
@@ -223,10 +242,10 @@ static int __init numa_emulation(uint64_t start_pfn, 
uint64_t end_pfn)
 }

 memset(&nodes,0,sizeof(nodes));
-for ( i = 0; i < numa_fake; i++ )
+for ( i = 0; i < get_numa_fake(); i++ )
 {
 nodes[i].start = (start_pfn << PAGE_SHIFT) + i * sz;
-if ( i == numa_fake - 1 )
+if ( i == get_numa_fake() - 1 )
 sz = (end_pfn << PAGE_SHIFT) - nodes[i].start;
 nodes[i].end = nodes[i].start + sz;
 printk(KERN_INFO
@@ -235,7 +254,7 @@ static int __init numa_emulation(uint64_t start_pfn, 
uint64_t end_pfn)
(nodes[i].end - nodes[i].start) >> 20);
 node_set_online(i);
 }
-if ( compute_memnode_shift(nodes, numa_fake, NULL, &memnode_shift) )
+if ( compute_memnode_shift(nodes, get_numa_fake(), NULL, &memnode_shift) )
 {
 memnode_shift = 0;
 printk(KERN_ERR "No NUMA hash function found. Emulation disabled.\n");
@@ -254,18 +273,18 @@ void __init numa_initmem_init(unsigned long start_pfn, 
unsigned long end_pfn)
 int i;

 #ifdef CONFIG_NUMA_EMU
-if ( numa_fake && !numa_emulation(start_pfn, end_pfn) )
+if ( get_numa_fake() && !numa_emulation(start_pfn, end_pfn) )
 return;
 #endif

 #ifdef CONFIG_ACPI_NUMA
-if ( !numa_off && !acpi_scan_nodes((uint64_t)start_pfn << PAGE_SHIFT,
+if ( !is_numa_off() && !acpi_scan_nodes((uint64_t)start_pfn << PAGE_SHIFT,
  (uint64_t)end_pfn << PAGE_SHIFT) )
 return;
 #endif

 printk(KERN_INFO "%s\n",
-   numa_off ? "NUMA turned off" : "No NUMA configuration found");
+   is_numa_off() ? "NUMA turned off" : "No NUMA configuration found");

 printk(KERN_INFO "Faking a node at %016"PRIx64"-%016"PRIx64"\n",
(uint64_t)start_pfn << PAGE_SHIFT,
@@ -312,7 +331,7 @@ static int __init numa_setup(char *opt)
 if ( !strncmp(opt,"noacpi",6) )
 {
 numa_off = 0;
-acpi_numa = -1;
+acpi_numa = 0;
 }
 #endif

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 1cd290e..4410e53 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -241,7 +241,7 @@ void srat_detect_node(int cpu)
 node_set_online(node);
 numa_set_node(cpu, node);

-if ( opt_cpu_info && acpi_numa > 0 )
+if ( opt_cpu_info && get_acpi_numa() )
 printk("CPU %d APIC %d -> Node %d\n", cpu, apicid, node);
 }

diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 2d0c047..ccacbcd 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -153,7 +153,7 @@ static void __init bad_srat(void)
 {
int i;
printk(KERN_ERR "SRAT: SRAT not used.\n");
-   acpi_numa = -1;
+   set_acpi_numa(0);
for (i = 0; i < MAX_LOCAL_APIC; i++)
apicid_to_node[i] = NUMA_NO_NODE;
for (i = 

[Xen-devel] Xen Project Security Team considering becoming a CNA

[Ian Jackson]

(Resending with the correct CC (!))

We are in discussions with MITRE with a view to potentially becoming a
CVE Numbering Authority.  This would probably smooth the process of
getting CVE numbers for XSAs.

If anyone has any opinions/representations/concerns/whatever about
this, please do share them (here in this thread, or privately to
security@).

Thanks,
Ian.

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

Re: [Xen-devel] superpages lost after migration of HVM domU

[Andrew Cooper]

On 20/04/17 16:35, Olaf Hering wrote:
> Andrew,
>
> with eab806a097b ("tools/libxc: x86 PV restore code") the only call of
> xc_domain_populate_physmap_exact was added to the new restore code.
> This call always sets order=0. The old migration code did consider
> superpages, the new one does not.
>
> What is the reason for not using superpages when populating a HVM domU?
>
> I supposed the first iteration would allocate all of the required memory
> for a domU, perhaps as superpages. ~ollowing iterations would just refill
> existing pages.

That was actually a bugfix for an existing migration failure, and at the
time I didn't consider the performance impact.  (At the time of
migration v2, post-migrate runtime performance was at the very bottom of
the priority list).

The calculations of when to use larger order allocations were buggy, and
could end up trying to allocate more than nr_pages, which causes a hard
failure of the migration.  This only ended up being a problem when
certain gfns had been ballooned out, but it resulted in a hard failure
on the destination side.

As it currently stands, the sending side iterates from 0 to p2m_size,
and sends every frame on the first pass.  This means we get PAGE_DATA
records linearly, in batches of 1024, or two aligned 2M superpages.

Therefore, it should be easy to tweak xc_sr_restore.c:populate_pfns() to
find ranges of 512 consecuative gfns of XEN_DOMCTL_PFINFO_NOTAB and make
a single order 9 allocation, rather than an 512 order 0 allocations.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/microcode: Use the return value from early_microcode_update_cpu

[Julien Grall]

Hi,

On 20/04/17 14:20, Andrew Cooper wrote:

On 20/04/17 14:18, Ross Lagerwall wrote:

Use the return value from early_microcode_update_cpu rather than
ignoring it.


Spotted by Coverity.



Signed-off-by: Ross Lagerwall 


Reviewed-by: Andrew Cooper 

Julien, can we have a release ack please?


Release-Acked-by: Julien Grall 

Cheers,



~Andrew



--
Julien Grall

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

Re: [Xen-devel] [PATCH] correct rcu_unlock_domain()

[Julien Grall]

Hi,

On 20/04/17 15:11, Andrew Cooper wrote:

On 20/04/17 14:48, Jan Beulich wrote:

Match rcu_lock_domain(), and remove the slightly misleading comment:
This isn't just the companion to rcu_lock_domain_by_id() (and that
latter function indeed also keeps the domain locked, not the domain
list).

No functional change, as rcu_read_{,un}lock() ignore their arguments
anyway.

Reported-by: Jann Horn 
Signed-off-by: Jan Beulich 


Reviewed-by: Andrew Cooper , although I think
it is worth stating in the commit message that the only reason this
currently works is because rcu_read_unlock() is entirely empty.


Release-acked-by: Julien Grall 

Cheers,





--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -584,11 +584,10 @@ int rcu_lock_remote_domain_by_id(domid_t
  */
 int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d);

-/* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
 if ( d != current->domain )
-rcu_read_unlock(&domlist_read_lock);
+rcu_read_unlock(d);
 }

 static inline struct domain *rcu_lock_domain(struct domain *d)







--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Vitaly Kuznetsov]

Peter Zijlstra  writes:

> On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
>> In this patch I suggest we set __max_logical_packages based on the
>> max_physical_pkg_id and total_cpus,
>
> So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
> instead of 4.
>
> This wastes quite a bit of memory for the per-node arrays. Luckily most
> are just pointer arrays, but still, wasting 140*8 bytes for each of
> them.
>
>> this should be safe and cover all
>> possible cases. Alternatively, we may think about eliminating the concept
>> of __max_logical_packages completely and relying on max_physical_pkg_id/
>> total_cpus where we currently use topology_max_packages().
>> 
>> The issue could've been solved in Xen too I guess. CPUID returning
>> x86_max_cores can be tweaked to be the lowerest(?) possible number of
>> all logical packages of the guest.
>
> This is getting ludicrous. Xen is plain broken, and instead of fixing
> it, you propose to somehow deal with its obviously crack induced
> behaviour :-(

Totally agree and I don't like the solution I propose (and that's why
this is RFC)... The problem is that there are such Xen setups in the
wild and with the recent changes some guests will BUG() :-(

Alternatively, we can just remove the BUG() and do something with CPUs
which have their pkg >= __max_logical_packages, e.g. assign them to the
last package. Far from ideal but will help to avoid the regression.

-- 
  Vitaly

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

Re: [Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Julien Grall]

Hi,

On 20/04/17 14:34, Jan Beulich wrote:

On 19.04.17 at 22:22,  wrote:

According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
"EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
and APIC ID are preserved when handling INIT signal and a reset places
APIC to xAPIC mode and APIC base address to 0xFEE0h (this part
is in "Local APIC" -> "Local APIC Status and Location"). So there are
two problems in current code:
1. Using reset logic (aka vlapic_reset) to handle INIT signal.
2. Forgetting resetting APIC mode and base address in vlapic_reset()

This patch introduces a new function vlapic_do_init() and replaces the
wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
in vlapic_reset().

Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
mode is unreasonable. This patch also doesn't reset LDR when handling INIT
signal in x2APIC mode.

Signed-off-by: Chao Gao 


Reviewed-by: Jan Beulich 


I regard this patch as a bug fix. But I haven't seen issues caused by
this bug and am not sure of the existance of such issues. Anyhow Cc
Julien and leave the decision to you (Julien and Jan).


Julien,

I'm slightly in favor of taking it now, but I won't object if you decide
otherwise.


Chao, can you assess the benefits/risks of having this patch in Xen 4.9?

Cheers,

--
Julien Grall

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

[Xen-devel] Xen Project Security Team considering becoming a CNA

[Ian Jackson]

We are in discussions with MITRE with a view to potentially becoming a
CVE Numbering Authority.  This would probably smooth the process of
getting CVE numbers for XSAs.

If anyone has any opinions/representations/concerns/whatever about
this, please do share them (here in this thread, or privately to
security@).

Thanks,
Ian.

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

[Xen-devel] superpages lost after migration of HVM domU

[Olaf Hering]

Andrew,

with eab806a097b ("tools/libxc: x86 PV restore code") the only call of
xc_domain_populate_physmap_exact was added to the new restore code.
This call always sets order=0. The old migration code did consider
superpages, the new one does not.

What is the reason for not using superpages when populating a HVM domU?

I supposed the first iteration would allocate all of the required memory
for a domU, perhaps as superpages. ~ollowing iterations would just refill
existing pages.

Olaf


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

[Xen-devel] [PATCH] x86/mm: also flush TLB when putting writable foreign page reference

[Jan Beulich]

Jann's explanation of the problem:

"start situation:
 - domain A and domain B are PV domains
 - domain A and B both have currently scheduled vCPUs, and the vCPUs
   are not scheduled away
 - domain A has XSM_TARGET access to domain B
 - page X is owned by domain B and has no mappings
 - page X is zeroed

 steps:
 - domain A uses do_mmu_update() to map page X in domain A as writable
 - domain A accesses page X through the new PTE, creating a TLB entry
 - domain A removes its mapping of page X
   - type count of page X goes to 0
   - tlbflush_timestamp of page X is bumped
 - domain B maps page X as L1 pagetable
   - type of page X changes to PGT_l1_page_table
   - TLB flush is forced using domain_dirty_cpumask of domain B
   - page X is mapped as L1 pagetable in domain B

 At this point, domain B's vCPUs are guaranteed to have no
 incorrectly-typed stale TLB entries for page X, but AFAICS domain A's
 vCPUs can still have stale TLB entries that map page X as writable,
 permitting domain A to control a live pagetable of domain B."

Domain A necessarily is Dom0 (DomU-s with XSM_TARGET permission are
being created only for HVM domains, but domain B needs to be PV here),
so this is not a security issue, but nevertheless seems desirable to
correct.

Reported-by: Jann Horn 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -602,6 +602,20 @@ static inline void guest_get_eff_kern_l1
 TOGGLE_MODE();
 }
 
+static const cpumask_t *get_flush_tlb_mask(const struct page_info *page,
+   const struct domain *d)
+{
+cpumask_t *mask = this_cpu(scratch_cpumask);
+
+BUG_ON(in_irq());
+cpumask_copy(mask, d->domain_dirty_cpumask);
+
+/* Don't flush if the timestamp is old enough */
+tlbflush_filter(mask, page->tlbflush_timestamp);
+
+return mask;
+}
+
 const char __section(".bss.page_aligned.const") __aligned(PAGE_SIZE)
 zero_page[PAGE_SIZE];
 
@@ -1266,6 +1280,23 @@ void put_page_from_l1e(l1_pgentry_t l1e,
 if ( (l1e_get_flags(l1e) & _PAGE_RW) && 
  ((l1e_owner == pg_owner) || !paging_mode_external(pg_owner)) )
 {
+/*
+ * Don't leave stale writable TLB entries in the unmapping domain's
+ * page tables, to prevent them allowing access to pages required to
+ * be read-only (e.g. after pg_owner changed them to page table or
+ * segment descriptor pages).
+ */
+if ( unlikely(l1e_owner != pg_owner) )
+{
+const cpumask_t *mask = get_flush_tlb_mask(page, l1e_owner);
+
+if ( !cpumask_empty(mask) )
+{
+perfc_incr(need_flush_tlb_flush);
+flush_tlb_mask(mask);
+}
+}
+
 put_page_and_type(page);
 }
 else
@@ -2545,13 +2576,7 @@ static int __get_page_type(struct page_i
  * may be unnecessary (e.g., page was GDT/LDT) but those 
  * circumstances should be very rare.
  */
-cpumask_t *mask = this_cpu(scratch_cpumask);
-
-BUG_ON(in_irq());
-cpumask_copy(mask, d->domain_dirty_cpumask);
-
-/* Don't flush if the timestamp is old enough */
-tlbflush_filter(mask, page->tlbflush_timestamp);
+const cpumask_t *mask = get_flush_tlb_mask(page, d);
 
 if ( unlikely(!cpumask_empty(mask)) &&
  /* Shadow mode: track only writable pages. */



x86/mm: also flush TLB when putting writable foreign page reference

Jann's explanation of the problem:

"start situation:
 - domain A and domain B are PV domains
 - domain A and B both have currently scheduled vCPUs, and the vCPUs
   are not scheduled away
 - domain A has XSM_TARGET access to domain B
 - page X is owned by domain B and has no mappings
 - page X is zeroed

 steps:
 - domain A uses do_mmu_update() to map page X in domain A as writable
 - domain A accesses page X through the new PTE, creating a TLB entry
 - domain A removes its mapping of page X
   - type count of page X goes to 0
   - tlbflush_timestamp of page X is bumped
 - domain B maps page X as L1 pagetable
   - type of page X changes to PGT_l1_page_table
   - TLB flush is forced using domain_dirty_cpumask of domain B
   - page X is mapped as L1 pagetable in domain B

 At this point, domain B's vCPUs are guaranteed to have no
 incorrectly-typed stale TLB entries for page X, but AFAICS domain A's
 vCPUs can still have stale TLB entries that map page X as writable,
 permitting domain A to control a live pagetable of domain B."

Domain A necessarily is Dom0 (DomU-s with XSM_TARGET permission are
being created only for HVM domains, but domain B needs to be PV here),
so this is not a security issue, but nevertheless seems desirable to
correct.

Reported-by: Jann Horn 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -602,6 +602,20 @@ static inline void guest_get_eff_ker

[Xen-devel] [PATCH v2 0/9] vpci: PCI config space emulation

[Roger Pau Monne]

Hello,

The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses to the
PCI configuration space and react accordingly.

Patch 1 implements the generic handlers for accesses to the PCI configuration
space together with a minimal user-space test harness that I've used during
development. Currently a per-device red-back tree is used in order to store the
list of handlers, and they are indexed based on their offset inside of the
configuration space. Patch 1 also adds the x86 port IO traps and wires them
into the newly introduced vPCI dispatchers. Patch 2 adds handlers for the ECAM
areas (as found on the MMCFG ACPI table). Patches 3 and 4 are mostly code
moment/refactoring in order to implement support for BAR mapping in patch 5.
Patch 6 allows Xen to mask certain PCI capabilities on-demand, which is used in
order to mask MSI and MSI-X.

Finally patches 8 and 9 implement support in order to emulate the MSI/MSI-X
capabilities inside of Xen, so that the interrupts are transparently routed to
the guest.

This series is based on top of my previous "x86/dpci: bind legacy PCI
interrupts to PVHv2 Dom0". The branch containing the patches can be found at:

git://xenbits.xen.org/people/royger/xen.git vpci_v2

Note that this is only safe to use for the hardware domain (that's trusted),
any non-trusted domain will need a lot more of traps before it can freely
access the PCI configuration space.

Thanks, Roger.


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

[Xen-devel] [PATCH v2 9/9] vpci/msix: add MSI-X handlers

[Roger Pau Monne]

Add handlers for accesses to the MSI-X message control field on the PCI
configuration space, and traps for accesses to the memory region that contains
the MSI-X table. This traps detect attempts from the guest to configure MSI-X
interrupts and properly sets them up.

Note that accesses to the Table Offset, Table BIR, PBA Offset, PBA BIR and the
PBA memory region itself are not trapped by Xen at the moment.

Whether Xen is going to provide this functionality to Dom0 (MSI-X emulation) is
controlled by the "msix" option in the dom0 field. When disabling this option
Xen will hide the MSI-X capability structure from Dom0.

Signed-off-by: Roger Pau Monné 
---
Jan Beulich 
Andrew Cooper 
---
This patch has been tested with devices using both a single MSI-X entry and
multiple ones.
---
 docs/misc/xen-command-line.markdown |   7 +
 xen/arch/x86/dom0_build.c   |   4 +
 xen/arch/x86/hvm/hvm.c  |   1 +
 xen/drivers/vpci/Makefile   |   2 +-
 xen/drivers/vpci/capabilities.c |  16 +-
 xen/drivers/vpci/header.c   |  38 ++-
 xen/drivers/vpci/msix.c | 590 
 xen/include/asm-x86/hvm/domain.h|   3 +
 xen/include/asm-x86/msi.h   |   1 +
 xen/include/xen/vpci.h  |  27 ++
 10 files changed, 669 insertions(+), 20 deletions(-)
 create mode 100644 xen/drivers/vpci/msix.c

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 38a8d05e63..2db2b49cb6 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -684,6 +684,13 @@ enabled.
 Enable or disable (using the `no-` prefix) the MSI emulation inside of
 Xen for a PVH Dom0. Note that this option has no effect on a PV Dom0.
 
+> `msix`
+
+> Default: `true`
+
+Enable or disable (using the `no-` prefix) the MSI-X emulation inside of
+Xen for a PVH Dom0. Note that this option has no effect on a PV Dom0.
+
 ### dtuart (ARM)
 > `= path [:options]`
 
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 01afcf6215..3996d9dd12 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -177,6 +177,7 @@ bool __initdata opt_dom0_shadow;
 #endif
 bool __initdata dom0_pvh;
 bool __initdata dom0_msi = true;
+bool __initdata dom0_msix = true;
 
 /*
  * List of parameters that affect Dom0 creation:
@@ -184,6 +185,7 @@ bool __initdata dom0_msi = true;
  *  - pvh   Create a PVHv2 Dom0.
  *  - shadowUse shadow paging for Dom0.
  *  - msi   MSI functionality.
+ *  - msix  MSI-X functionality.
  */
 static void __init parse_dom0_param(char *s)
 {
@@ -207,6 +209,8 @@ static void __init parse_dom0_param(char *s)
 #endif
 else if ( !strcmp(s, "msi") )
 dom0_msi = enabled;
+else if ( !strcmp(s, "msix") )
+dom0_msix = enabled;
 
 s = ss + 1;
 } while ( ss );
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ef3ad2a615..3a3296ffe7 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -614,6 +614,7 @@ int hvm_domain_initialise(struct domain *d)
 INIT_LIST_HEAD(&d->arch.hvm_domain.write_map.list);
 INIT_LIST_HEAD(&d->arch.hvm_domain.g2m_ioport_list);
 INIT_LIST_HEAD(&d->arch.hvm_domain.ecam_regions);
+INIT_LIST_HEAD(&d->arch.hvm_domain.msix_tables);
 
 hvm_init_cacheattr_region_list(d);
 
diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index ef4fc6caf3..55398d4428 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1 +1 @@
-obj-y += vpci.o header.o capabilities.o msi.o
+obj-y += vpci.o header.o capabilities.o msi.o msix.o
diff --git a/xen/drivers/vpci/capabilities.c b/xen/drivers/vpci/capabilities.c
index ad9f45c2e1..7166ccb502 100644
--- a/xen/drivers/vpci/capabilities.c
+++ b/xen/drivers/vpci/capabilities.c
@@ -130,21 +130,7 @@ void xen_vpci_mask_capability(struct pci_dev *pdev, 
uint8_t cap_id)
 }
 }
 
-static int vpci_capabilities_init(struct pci_dev *pdev)
-{
-int rc;
-
-rc = vpci_index_capabilities(pdev);
-if ( rc )
-return rc;
-
-/* Mask MSI-X capability until Xen handles it. */
-xen_vpci_mask_capability(pdev, PCI_CAP_ID_MSIX);
-
-return 0;
-}
-
-REGISTER_VPCI_INIT(vpci_capabilities_init, true);
+REGISTER_VPCI_INIT(vpci_index_capabilities, true);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index d77d82455f..d1e3dfb9f0 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -32,15 +32,45 @@ static int vpci_modify_bars(struct pci_dev *pdev, const 
bool map)
 paddr_t gaddr = map ? header->bars[i].gaddr
 : header->bars[i].mapped_addr;
 paddr_t paddr = header->bars[i].paddr;
+size_t size = header->bars[i].size;
 
 if ( header->bars[i].type != VPCI_BAR_MEM &&
  header->bars[i].type != VPCI_BAR_MEM64_LO )
 continue;
 
-  

[Xen-devel] [PATCH v2 6/9] xen/vpci: trap access to the list of PCI capabilities

[Roger Pau Monne]

Add traps to each capability PCI_CAP_LIST_NEXT field in order to mask them on
request.

All capabilities from the device are fetched and stored in an internal list,
that's later used in order to return the next capability to the guest. Note
that this only removes the capability from the linked list as seen by the
guest, but the actual capability structure could still be accessed by the
guest, provided that it's position can be found using another mechanism.
Finally the MSI and MSI-X capabilities are masked until Xen knows how to
properly handle accesses to them.

This should allow a PVH Dom0 to boot on some hardware, provided that the
hardware doesn't require MSI/MSI-X and that there are no SR-IOV devices in the
system, so the panic at the end of the PVH Dom0 build is replaced by a
warning.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Add missing newline between cmd handlers.
 - Switch the handler to use list_for_each_entry_continue instead of a wrong
   open-coded version of it.
---
 xen/arch/x86/hvm/dom0_build.c   |   2 +-
 xen/drivers/vpci/Makefile   |   2 +-
 xen/drivers/vpci/capabilities.c | 159 
 xen/include/xen/vpci.h  |   3 +
 4 files changed, 164 insertions(+), 2 deletions(-)
 create mode 100644 xen/drivers/vpci/capabilities.c

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 65f606d33a..bcd10bd69c 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1097,7 +1097,7 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 return rc;
 }
 
-panic("Building a PVHv2 Dom0 is not yet supported.");
+printk("WARNING: PVH is an experimental mode with limited 
functionality\n");
 return 0;
 }
 
diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index 241467212f..c3f3085c93 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1 +1 @@
-obj-y += vpci.o header.o
+obj-y += vpci.o header.o capabilities.o
diff --git a/xen/drivers/vpci/capabilities.c b/xen/drivers/vpci/capabilities.c
new file mode 100644
index 00..b2a3326aa7
--- /dev/null
+++ b/xen/drivers/vpci/capabilities.c
@@ -0,0 +1,159 @@
+/*
+ * Generic functionality for handling accesses to the PCI capabilities from
+ * the configuration space.
+ *
+ * Copyright (C) 2017 Citrix Systems R&D
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+
+struct vpci_capability {
+struct list_head next;
+uint8_t offset;
+bool masked;
+};
+
+static int vpci_cap_read(struct pci_dev *pdev, unsigned int reg,
+ union vpci_val *val, void *data)
+{
+struct vpci_capability *cap = data;
+
+val->half_word = 0;
+
+/* Return the position of the next non-masked capability. */
+list_for_each_entry_continue ( cap, &pdev->vpci->cap_list, next )
+{
+if ( !cap->masked )
+{
+val->half_word = cap->offset;
+break;
+}
+}
+
+return 0;
+}
+
+static int vpci_cap_write(struct pci_dev *pdev, unsigned int reg,
+  union vpci_val val, void *data)
+{
+/* Ignored. */
+return 0;
+}
+
+static int vpci_index_capabilities(struct pci_dev *pdev)
+{
+uint8_t seg = pdev->seg, bus = pdev->bus;
+uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn);
+uint8_t pos = PCI_CAPABILITY_LIST;
+uint16_t status;
+unsigned int max_cap = 48;
+struct vpci_capability *cap;
+int rc;
+
+INIT_LIST_HEAD(&pdev->vpci->cap_list);
+
+/* Check if device has capabilities. */
+status = pci_conf_read16(seg, bus, slot, func, PCI_STATUS);
+if ( !(status & PCI_STATUS_CAP_LIST) )
+return 0;
+
+/* Add the root capability pointer. */
+cap = xzalloc(struct vpci_capability);
+if ( !cap )
+return -ENOMEM;
+
+cap->offset = pos;
+list_add_tail(&cap->next, &pdev->vpci->cap_list);
+rc = xen_vpci_add_register(pdev, vpci_cap_read, vpci_cap_write, pos,
+   1, cap);
+if ( rc )
+return rc;
+
+/*
+ * Iterate over the list of capabilities present in the device, and
+ * add a handler for each register pointer to the next item
+ * (PCI_CAP_LIST_NEXT).
+ */
+while ( max_cap-- )
+{
+pos = pci_conf_read8(seg, bus, slot, fu

[Xen-devel] [PATCH v2 8/9] vpci/msi: add MSI handlers

[Roger Pau Monne]

Add handlers for the MSI control, address, data and mask fields in order to
detect accesses to them and setup the interrupts as requested by the guest.

Note that the pending register is not trapped, and the guest can freely
read/write to it.

Whether Xen is going to provide this functionality to Dom0 (MSI emulation) is
controlled by the "msi" option in the dom0 field. When disabling this option
Xen will hide the MSI capability structure from Dom0.

Signed-off-by: Roger Pau Monné 
---
Jan Beulich 
Andrew Cooper 
Paul Durrant 
---
NB: I've only been able to test this with devices using a single MSI interrupt
and no mask register. I will try to find hardware that supports the mask
register and more than one vector, but I cannot make any promises.

If there are doubts about the untested parts we could always force Xen to
report no per-vector masking support and only 1 available vector, but I would
rather avoid doing it.
---
 docs/misc/xen-command-line.markdown |   9 +-
 xen/arch/x86/dom0_build.c   |  12 +-
 xen/arch/x86/hvm/vmsi.c |  21 ++
 xen/drivers/vpci/Makefile   |   2 +-
 xen/drivers/vpci/capabilities.c |   7 +-
 xen/drivers/vpci/msi.c  | 469 
 xen/include/asm-x86/hvm/io.h|   4 +
 xen/include/asm-x86/msi.h   |   2 +
 xen/include/xen/hvm/irq.h   |   1 +
 xen/include/xen/vpci.h  |  26 ++
 10 files changed, 545 insertions(+), 8 deletions(-)
 create mode 100644 xen/drivers/vpci/msi.c

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 450b222734..38a8d05e63 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -660,7 +660,7 @@ affinities to prefer but be not limited to the specified 
node(s).
 Pin dom0 vcpus to their respective pcpus
 
 ### dom0
-> `= List of [ pvh | shadow ]`
+> `= List of [ pvh | shadow | msi ]`
 
 > Sub-options:
 
@@ -677,6 +677,13 @@ Flag that makes a dom0 boot in PVHv2 mode.
 Flag that makes a dom0 use shadow paging. Only works when "pvh" is
 enabled.
 
+> `msi`
+
+> Default: `true`
+
+Enable or disable (using the `no-` prefix) the MSI emulation inside of
+Xen for a PVH Dom0. Note that this option has no effect on a PV Dom0.
+
 ### dtuart (ARM)
 > `= path [:options]`
 
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index cc8acad688..01afcf6215 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -176,29 +176,37 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 bool __initdata opt_dom0_shadow;
 #endif
 bool __initdata dom0_pvh;
+bool __initdata dom0_msi = true;
 
 /*
  * List of parameters that affect Dom0 creation:
  *
  *  - pvh   Create a PVHv2 Dom0.
  *  - shadowUse shadow paging for Dom0.
+ *  - msi   MSI functionality.
  */
 static void __init parse_dom0_param(char *s)
 {
 char *ss;
+bool enabled;
 
 do {
+enabled = !!strncmp(s, "no-", 3);
+if ( !enabled )
+s += 3;
 
 ss = strchr(s, ',');
 if ( ss )
 *ss = '\0';
 
 if ( !strcmp(s, "pvh") )
-dom0_pvh = true;
+dom0_pvh = enabled;
 #ifdef CONFIG_SHADOW_PAGING
 else if ( !strcmp(s, "shadow") )
-opt_dom0_shadow = true;
+opt_dom0_shadow = enabled;
 #endif
+else if ( !strcmp(s, "msi") )
+dom0_msi = enabled;
 
 s = ss + 1;
 } while ( ss );
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index a36692c313..614d975efe 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -622,3 +622,24 @@ void msix_write_completion(struct vcpu *v)
 if ( msixtbl_write(v, ctrl_address, 4, 0) != X86EMUL_OKAY )
 gdprintk(XENLOG_WARNING, "MSI-X write completion failure\n");
 }
+
+unsigned int msi_vector(uint16_t data)
+{
+return (data & MSI_DATA_VECTOR_MASK) >> MSI_DATA_VECTOR_SHIFT;
+}
+
+unsigned int msi_flags(uint16_t data, uint64_t addr)
+{
+unsigned int rh, dm, dest_id, deliv_mode, trig_mode;
+
+rh = (addr >> MSI_ADDR_REDIRECTION_SHIFT) & 0x1;
+dm = (addr >> MSI_ADDR_DESTMODE_SHIFT) & 0x1;
+dest_id = (addr & MSI_ADDR_DEST_ID_MASK) >> MSI_ADDR_DEST_ID_SHIFT;
+deliv_mode = (data >> MSI_DATA_DELIVERY_MODE_SHIFT) & 0x7;
+trig_mode = (data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
+
+return dest_id | (rh << GFLAGS_SHIFT_RH) | (dm << GFLAGS_SHIFT_DM) |
+   (deliv_mode << GFLAGS_SHIFT_DELIV_MODE) |
+   (trig_mode << GFLAGS_SHIFT_TRG_MODE);
+}
+
diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index c3f3085c93..ef4fc6caf3 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1 +1 @@
-obj-y += vpci.o header.o capabilities.o
+obj-y += vpci.o header.o capabilities.o msi.o
diff --git a/xen/drivers/vpci/capabilities.c b/xen/drivers/vpci/capabilities.c
index 204355e673..ad9f45c2e1 100644
--- a/xen/drivers/vpc

[Xen-devel] [PATCH v2 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

[Roger Pau Monne]

This functionality is going to reside in vpci.c (and the corresponding vpci.h
header), and should be arch-agnostic. The handlers introduced in this patch
setup the basic functionality required in order to trap accesses to the PCI
config space, and allow decoding the address and finding the corresponding
handler that should handle the access (although no handlers are implemented).

Note that the traps to the PCI IO ports registers (0xcf8/0xcfc) are setup
inside of a x86 HVM file, since that's not shared with other arches.

A new XEN_X86_EMU_VPCI x86 domain flag is added in order to signal Xen whether
a domain should use the newly introduced vPCI handlers, this is only enabled
for PVH Dom0 at the moment.

A very simple user-space test is also provided, so that the basic functionality
of the vPCI traps can be asserted. This has been proven quite helpful during
development, since the logic to handle partial accesses or accesses that expand
across multiple registers is not trivial.

The handlers for the registers are added to a red-black tree, that indexes them
based on their offset. Since Xen needs to handle partial accesses to the
registers and access that expand across multiple registers the logic in
xen_vpci_{read/write} is kind of convoluted, I've tried to properly comment it
in order to make it easier to understand.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
Changes since v1:
 - Allow access to cross a word-boundary.
 - Add locking.
 - Add cleanup to xen_vpci_add_handlers in case of failure.
---
 .gitignore|   4 +
 tools/libxl/libxl_x86.c   |   2 +-
 tools/tests/Makefile  |   1 +
 tools/tests/vpci/Makefile |  45 
 tools/tests/vpci/emul.h   | 107 +
 tools/tests/vpci/main.c   | 206 +
 xen/arch/arm/xen.lds.S|   3 +
 xen/arch/x86/domain.c |  18 +-
 xen/arch/x86/hvm/hvm.c|   2 +
 xen/arch/x86/hvm/io.c | 135 +++
 xen/arch/x86/setup.c  |   3 +-
 xen/arch/x86/xen.lds.S|   3 +
 xen/drivers/Makefile  |   2 +-
 xen/drivers/passthrough/pci.c |   3 +
 xen/drivers/vpci/Makefile |   1 +
 xen/drivers/vpci/vpci.c   | 474 ++
 xen/include/asm-x86/domain.h  |   1 +
 xen/include/asm-x86/hvm/domain.h  |   3 +
 xen/include/asm-x86/hvm/io.h  |   3 +
 xen/include/public/arch-x86/xen.h |   5 +-
 xen/include/xen/pci.h |   4 +
 xen/include/xen/vpci.h|  66 ++
 22 files changed, 1083 insertions(+), 8 deletions(-)
 create mode 100644 tools/tests/vpci/Makefile
 create mode 100644 tools/tests/vpci/emul.h
 create mode 100644 tools/tests/vpci/main.c
 create mode 100644 xen/drivers/vpci/Makefile
 create mode 100644 xen/drivers/vpci/vpci.c
 create mode 100644 xen/include/xen/vpci.h

diff --git a/.gitignore b/.gitignore
index 74747cb7e7..ebafba25b5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -236,6 +236,10 @@ tools/tests/regression/build/*
 tools/tests/regression/downloads/*
 tools/tests/mem-sharing/memshrtool
 tools/tests/mce-test/tools/xen-mceinj
+tools/tests/vpci/rbtree.[hc]
+tools/tests/vpci/vpci.[hc]
+tools/tests/vpci/test_vpci.out
+tools/tests/vpci/test_vpci
 tools/xcutils/lsevtchn
 tools/xcutils/readnotes
 tools/xenbackendd/_paths.h
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 455f6f0bed..dd7fc78a99 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -11,7 +11,7 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
 if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM) {
 if (d_config->b_info.device_model_version !=
 LIBXL_DEVICE_MODEL_VERSION_NONE) {
-xc_config->emulation_flags = XEN_X86_EMU_ALL;
+xc_config->emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
 } else if (libxl_defbool_val(d_config->b_info.u.hvm.apic)) {
 /*
  * HVM guests without device model may want
diff --git a/tools/tests/Makefile b/tools/tests/Makefile
index 639776130b..5cfe781e62 100644
--- a/tools/tests/Makefile
+++ b/tools/tests/Makefile
@@ -13,6 +13,7 @@ endif
 SUBDIRS-$(CONFIG_X86) += x86_emulator
 SUBDIRS-y += xen-access
 SUBDIRS-y += xenstore
+SUBDIRS-$(CONFIG_HAS_PCI) += vpci
 
 .PHONY: all clean install distclean
 all clean distclean: %: subdirs-%
diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
new file mode 100644
index 00..7969fcbd82
--- /dev/null
+++ b/tools/tests/vpci/Makefile
@@ -0,0 +1,45 @@
+
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+TARGET := test_vpci
+
+.PHONY: all
+all: $(TARGET)
+
+.PHONY: run
+run: $(TARGET)
+   ./$(TARGET) > $(TARGET).out
+
+$(TARGET): vpci.c vpci.h rbtree.c rbtree.h
+   $(HOSTCC) -g -o $@ vpci.c main.c rbtree.c
+
+.PHONY: clean
+clean:
+   rm -rf $(TARGET) $(TARGET).out *.o *~ vp

[Xen-devel] [PATCH v2 3/9] xen/mm: move modify_identity_mmio to global file and drop __init

[Roger Pau Monne]

And also allow it to do non-identity mappings by adding a new parameter. This
function will be needed in other parts apart from PVH Dom0 build.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/dom0_build.c | 22 +-
 xen/common/memory.c   | 34 ++
 xen/include/xen/p2m-common.h  |  4 
 3 files changed, 39 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index ca88c5835e..65f606d33a 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -64,27 +64,7 @@ static struct acpi_madt_nmi_source __initdata *nmisrc;
 static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
unsigned long nr_pages, const bool map)
 {
-int rc;
-
-for ( ; ; )
-{
-rc = (map ? map_mmio_regions : unmap_mmio_regions)
- (d, _gfn(pfn), nr_pages, _mfn(pfn));
-if ( rc == 0 )
-break;
-if ( rc < 0 )
-{
-printk(XENLOG_WARNING
-   "Failed to identity %smap [%#lx,%#lx) for d%d: %d\n",
-   map ? "" : "un", pfn, pfn + nr_pages, d->domain_id, rc);
-break;
-}
-nr_pages -= rc;
-pfn += rc;
-process_pending_softirqs();
-}
-
-return rc;
+return modify_mmio(d, pfn, pfn, nr_pages, map);
 }
 
 /* Populate a HVM memory range using the biggest possible order. */
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 52879e7438..0d970482cb 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1438,6 +1438,40 @@ int prepare_ring_for_helper(
 return 0;
 }
 
+int modify_mmio(struct domain *d, unsigned long gfn, unsigned long pfn,
+unsigned long nr_pages, const bool map)
+{
+int rc;
+
+/*
+ * Make sure this function is only used by the hardware domain, because it
+ * can take an arbitrary long time, and could DoS the whole system.
+ */
+ASSERT(is_hardware_domain(d));
+
+for ( ; ; )
+{
+rc = (map ? map_mmio_regions : unmap_mmio_regions)
+ (d, _gfn(gfn), nr_pages, _mfn(pfn));
+if ( rc == 0 )
+break;
+if ( rc < 0 )
+{
+printk(XENLOG_WARNING
+   "Failed to %smap [%#lx, %#lx) -> [%#lx,%#lx) for d%d: %d\n",
+   map ? "" : "un", gfn, gfn + nr_pages, pfn, pfn + nr_pages,
+   d->domain_id, rc);
+break;
+}
+nr_pages -= rc;
+pfn += rc;
+gfn += rc;
+process_pending_softirqs();
+}
+
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/p2m-common.h b/xen/include/xen/p2m-common.h
index 8cd5a6b503..1308da44e7 100644
--- a/xen/include/xen/p2m-common.h
+++ b/xen/include/xen/p2m-common.h
@@ -13,4 +13,8 @@ int unmap_mmio_regions(struct domain *d,
unsigned long nr,
mfn_t mfn);
 
+
+int modify_mmio(struct domain *d, unsigned long gfn, unsigned long pfn,
+unsigned long nr_pages, const bool map);
+
 #endif /* _XEN_P2M_COMMON_H */
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH v2 5/9] xen/vpci: add handlers to map the BARs

[Roger Pau Monne]

Introduce a set of handlers that trap accesses to the PCI BARs and the command
register, in order to emulate BAR sizing and BAR relocation.

The command handler is used to detect changes to bit 2 (response to memory
space accesses), and maps/unmaps the BARs of the device into the guest p2m.

The BAR register handlers are used to detect attempts by the guest to size or
relocate the BARs.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/drivers/vpci/Makefile |   2 +-
 xen/drivers/vpci/header.c | 270 ++
 xen/include/xen/vpci.h|  27 +
 3 files changed, 298 insertions(+), 1 deletion(-)
 create mode 100644 xen/drivers/vpci/header.c

diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index 840a906470..241467212f 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1 +1 @@
-obj-y += vpci.o
+obj-y += vpci.o header.o
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
new file mode 100644
index 00..80c329
--- /dev/null
+++ b/xen/drivers/vpci/header.c
@@ -0,0 +1,270 @@
+/*
+ * Generic functionality for handling accesses to the PCI header from the
+ * configuration space.
+ *
+ * Copyright (C) 2017 Citrix Systems R&D
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+static int vpci_modify_bars(struct pci_dev *pdev, const bool map)
+{
+struct vpci_header *header = &pdev->vpci->header;
+unsigned int i;
+int rc = 0;
+
+for ( i = 0; i < ARRAY_SIZE(header->bars); i++ )
+{
+paddr_t gaddr = map ? header->bars[i].gaddr
+: header->bars[i].mapped_addr;
+paddr_t paddr = header->bars[i].paddr;
+
+if ( header->bars[i].type != VPCI_BAR_MEM &&
+ header->bars[i].type != VPCI_BAR_MEM64_LO )
+continue;
+
+rc = modify_mmio(pdev->domain, PFN_DOWN(gaddr), PFN_DOWN(paddr),
+ PFN_UP(header->bars[i].size), map);
+if ( rc )
+break;
+
+header->bars[i].mapped_addr = map ? gaddr : 0;
+}
+
+return rc;
+}
+
+static int vpci_cmd_read(struct pci_dev *pdev, unsigned int reg,
+ union vpci_val *val, void *data)
+{
+struct vpci_header *header = data;
+
+val->word = header->command;
+
+return 0;
+}
+
+static int vpci_cmd_write(struct pci_dev *pdev, unsigned int reg,
+  union vpci_val val, void *data)
+{
+struct vpci_header *header = data;
+uint16_t new_cmd, saved_cmd;
+uint8_t seg = pdev->seg, bus = pdev->bus;
+uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn);
+int rc;
+
+new_cmd = val.word;
+saved_cmd = header->command;
+
+if ( !((new_cmd ^ saved_cmd) & PCI_COMMAND_MEMORY) )
+goto out;
+
+/* Memory space access change. */
+rc = vpci_modify_bars(pdev, new_cmd & PCI_COMMAND_MEMORY);
+if ( rc )
+{
+dprintk(XENLOG_ERR,
+"%04x:%02x:%02x.%u:unable to %smap BARs: %d\n",
+seg, bus, slot, func,
+new_cmd & PCI_COMMAND_MEMORY ? "" : "un", rc);
+return rc;
+}
+
+ out:
+pci_conf_write16(seg, bus, slot, func, reg, new_cmd);
+header->command = pci_conf_read16(seg, bus, slot, func, reg);
+return 0;
+}
+
+static int vpci_bar_read(struct pci_dev *pdev, unsigned int reg,
+ union vpci_val *val, void *data)
+{
+struct vpci_bar *bar = data;
+bool hi = false;
+
+ASSERT(bar->type == VPCI_BAR_MEM || bar->type == VPCI_BAR_MEM64_LO ||
+   bar->type == VPCI_BAR_MEM64_HI);
+
+if ( bar->type == VPCI_BAR_MEM64_HI )
+{
+ASSERT(reg - PCI_BASE_ADDRESS_0 > 0);
+bar--;
+hi = true;
+}
+
+if ( bar->sizing )
+val->double_word = ~(bar->size - 1) >> (hi ? 32 : 0);
+else
+val->double_word = bar->gaddr >> (hi ? 32 : 0);
+
+val->double_word |= hi ? 0 : bar->attributes;
+
+return 0;
+}
+
+static int vpci_bar_write(struct pci_dev *pdev, unsigned int reg,
+  union vpci_val val, void *data)
+{
+struct vpci_bar *bar = data;
+uint32_t wdata = val.double_word;
+bool hi = false;
+
+ASSERT(bar->type == VPCI_BAR_MEM || bar->type == 

[Xen-devel] [PATCH v2 7/9] vpci: add a priority field to the vPCI register initializer

[Roger Pau Monne]

And mark the capability and header vPCI register initializers as high priority,
so that they are initialized first.

This is needed for MSI-X, since MSI-X needs to know the position of the BARs in
order to perform it's initialization, and in order to mask or enable the
MSI/MSI-X functionality on demand.

Signed-off-by: Roger Pau Monné 
---
Jan Beulich 
Andrew Cooper 
---
 tools/tests/vpci/Makefile   |  4 ++--
 xen/drivers/vpci/capabilities.c |  2 +-
 xen/drivers/vpci/header.c   |  2 +-
 xen/drivers/vpci/vpci.c | 14 --
 xen/include/xen/vpci.h  | 13 +++--
 5 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/tools/tests/vpci/Makefile b/tools/tests/vpci/Makefile
index 7969fcbd82..e5edc4f512 100644
--- a/tools/tests/vpci/Makefile
+++ b/tools/tests/vpci/Makefile
@@ -31,8 +31,8 @@ vpci.c: $(XEN_ROOT)/xen/drivers/vpci/vpci.c
# Trick the compiler so it doesn't complain about missing symbols
sed -e '/#include/d' \
-e '1s;^;#include "emul.h"\
-const vpci_register_init_t __start_vpci_array[1]\;\
-const vpci_register_init_t __end_vpci_array[1]\;\
+const struct vpci_register_init __start_vpci_array[1]\;\
+const struct vpci_register_init __end_vpci_array[1]\;\
 ;' <$< >$@
 
 rbtree.h: $(XEN_ROOT)/xen/include/xen/rbtree.h
diff --git a/xen/drivers/vpci/capabilities.c b/xen/drivers/vpci/capabilities.c
index b2a3326aa7..204355e673 100644
--- a/xen/drivers/vpci/capabilities.c
+++ b/xen/drivers/vpci/capabilities.c
@@ -145,7 +145,7 @@ static int vpci_capabilities_init(struct pci_dev *pdev)
 return 0;
 }
 
-REGISTER_VPCI_INIT(vpci_capabilities_init);
+REGISTER_VPCI_INIT(vpci_capabilities_init, true);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 80c329..d77d82455f 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -256,7 +256,7 @@ static int vpci_init_bars(struct pci_dev *pdev)
 return 0;
 }
 
-REGISTER_VPCI_INIT(vpci_init_bars);
+REGISTER_VPCI_INIT(vpci_init_bars, true);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
index f4cd04f11d..9f9abadbdb 100644
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -20,7 +20,7 @@
 #include 
 #include 
 
-extern const vpci_register_init_t __start_vpci_array[], __end_vpci_array[];
+extern const struct vpci_register_init __start_vpci_array[], 
__end_vpci_array[];
 #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)
 #define vpci_init __start_vpci_array
 
@@ -42,6 +42,7 @@ struct vpci_register {
 int xen_vpci_add_handlers(struct pci_dev *pdev)
 {
 int i, rc = 0;
+bool priority = true;
 
 if ( !has_vpci(pdev->domain) )
 return 0;
@@ -52,9 +53,13 @@ int xen_vpci_add_handlers(struct pci_dev *pdev)
 
 pdev->vpci->handlers = RB_ROOT;
 
+ again:
 for ( i = 0; i < NUM_VPCI_INIT; i++ )
 {
-rc = vpci_init[i](pdev);
+if ( priority != vpci_init[i].priority )
+continue;
+
+rc = vpci_init[i].init(pdev);
 if ( rc )
 break;
 }
@@ -74,6 +79,11 @@ int xen_vpci_add_handlers(struct pci_dev *pdev)
 }
 xfree(pdev->vpci);
 }
+else if ( priority )
+{
+priority = false;
+goto again;
+}
 
 return rc;
 }
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 53443f5164..75564b9d93 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -29,8 +29,17 @@ typedef int (*vpci_write_t)(struct pci_dev *pdev, unsigned 
int reg,
 
 typedef int (*vpci_register_init_t)(struct pci_dev *dev);
 
-#define REGISTER_VPCI_INIT(x) \
-  static const vpci_register_init_t x##_entry __used_section(".data.vpci") = x
+struct vpci_register_init {
+vpci_register_init_t init;
+bool priority;
+};
+
+#define REGISTER_VPCI_INIT(f, p)\
+  static const struct vpci_register_init\
+  x##_entry __used_section(".data.vpci") = {\
+.init = f,  \
+.priority = p,  \
+}
 
 /* Add vPCI handlers to device. */
 int xen_vpci_add_handlers(struct pci_dev *dev);
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH v2 2/9] x86/ecam: add handlers for the PVH Dom0 MMCFG areas

[Roger Pau Monne]

Introduce a set of handlers for the accesses to the ECAM areas. Those areas are
setup based on the contents of the hardware MMCFG tables, and the list of
handled ECAM areas is stored inside of the hvm_domain struct.

The read/writes are forwarded to the generic vpci handlers once the address is
decoded in order to obtain the device and register the guest is trying to
access.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
Changes since v1:
 - Added locking.
---
 xen/arch/x86/hvm/dom0_build.c|  27 
 xen/arch/x86/hvm/hvm.c   |  10 +++
 xen/arch/x86/hvm/io.c| 135 +++
 xen/include/asm-x86/hvm/domain.h |  10 +++
 xen/include/asm-x86/hvm/io.h |   4 ++
 5 files changed, 186 insertions(+)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 020c355faf..ca88c5835e 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 
+#include "../x86_64/mmconfig.h"
+
 /*
  * Have the TSS cover the ISA port range, which makes it
  * - 104 bytes base structure
@@ -1048,6 +1050,24 @@ static int __init pvh_setup_acpi(struct domain *d, 
paddr_t start_info)
 return 0;
 }
 
+int __init pvh_setup_ecam(struct domain *d)
+{
+unsigned int i;
+int rc;
+
+for ( i = 0; i < pci_mmcfg_config_num; i++ )
+{
+size_t size = (pci_mmcfg_config[i].end_bus_number + 1) << 20;
+
+rc = register_vpci_ecam_handler(d, pci_mmcfg_config[i].address, size,
+pci_mmcfg_config[i].pci_segment);
+if ( rc )
+return rc;
+}
+
+return 0;
+}
+
 int __init dom0_construct_pvh(struct domain *d, const module_t *image,
   unsigned long image_headroom,
   module_t *initrd,
@@ -1090,6 +1110,13 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 return rc;
 }
 
+rc = pvh_setup_ecam(d);
+if ( rc )
+{
+printk("Failed to setup Dom0 PCI ECAM areas: %d\n", rc);
+return rc;
+}
+
 panic("Building a PVHv2 Dom0 is not yet supported.");
 return 0;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7f3322ede6..ef3ad2a615 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -613,6 +613,7 @@ int hvm_domain_initialise(struct domain *d)
 spin_lock_init(&d->arch.hvm_domain.write_map.lock);
 INIT_LIST_HEAD(&d->arch.hvm_domain.write_map.list);
 INIT_LIST_HEAD(&d->arch.hvm_domain.g2m_ioport_list);
+INIT_LIST_HEAD(&d->arch.hvm_domain.ecam_regions);
 
 hvm_init_cacheattr_region_list(d);
 
@@ -725,6 +726,7 @@ void hvm_domain_destroy(struct domain *d)
 {
 struct list_head *ioport_list, *tmp;
 struct g2m_ioport *ioport;
+struct hvm_ecam *ecam, *etmp;
 
 xfree(d->arch.hvm_domain.io_handler);
 d->arch.hvm_domain.io_handler = NULL;
@@ -752,6 +754,14 @@ void hvm_domain_destroy(struct domain *d)
 list_del(&ioport->list);
 xfree(ioport);
 }
+
+list_for_each_entry_safe ( ecam, etmp, &d->arch.hvm_domain.ecam_regions,
+   next )
+{
+list_del(&ecam->next);
+xfree(ecam);
+}
+
 }
 
 static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 15048da556..319cf9287b 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -391,6 +391,141 @@ void register_vpci_portio_handler(struct domain *d)
 handler->ops = &vpci_portio_ops;
 }
 
+/* Handlers to trap PCI ECAM config accesses. */
+static struct hvm_ecam *vpci_ecam_find(struct domain *d, unsigned long addr)
+{
+struct hvm_ecam *ecam = NULL;
+
+ASSERT(vpci_locked(d));
+list_for_each_entry ( ecam, &d->arch.hvm_domain.ecam_regions, next )
+if ( addr >= ecam->addr && addr < ecam->addr + ecam->size )
+return ecam;
+
+return NULL;
+}
+
+static void vpci_ecam_decode_addr(unsigned long addr, unsigned int *bus,
+  unsigned int *devfn, unsigned int *reg)
+{
+*bus = (addr >> 20) & 0xff;
+*devfn = (addr >> 12) & 0xff;
+*reg = addr & 0xfff;
+}
+
+static int vpci_ecam_accept(struct vcpu *v, unsigned long addr)
+{
+struct domain *d = v->domain;
+int found;
+
+vpci_lock(d);
+found = !!vpci_ecam_find(v->domain, addr);
+vpci_unlock(d);
+
+return found;
+}
+
+static int vpci_ecam_read(struct vcpu *v, unsigned long addr,
+  unsigned int len, unsigned long *data)
+{
+struct domain *d = v->domain;
+struct hvm_ecam *ecam;
+unsigned int bus, devfn, reg;
+uint32_t data32;
+int rc;
+
+vpci_lock(d);
+ecam = vpci_ecam_find(d, addr);
+if ( !ecam )
+{
+vpci_unlock(d);
+return X86EMUL_UNHANDLEABLE;
+}
+
+vpci_ecam_decode_addr(addr - ecam

[Xen-devel] [PATCH v2 4/9] xen/pci: split code to size BARs from pci_add_device

[Roger Pau Monne]

So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
 xen/drivers/passthrough/pci.c | 86 ++-
 xen/include/xen/pci.h |  3 ++
 2 files changed, 56 insertions(+), 33 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 2288cf8814..7710c41533 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -588,6 +588,51 @@ static void pci_enable_acs(struct pci_dev *pdev)
 pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
 }
 
+int pci_size_bar(unsigned int seg, unsigned int bus, unsigned int slot,
+ unsigned int func, unsigned int base, unsigned int max_bars,
+ unsigned int *index, uint64_t *addr, uint64_t *size)
+{
+unsigned int idx = base + *index * 4;
+u32 bar = pci_conf_read32(seg, bus, slot, func, idx);
+u32 hi = 0;
+
+*addr = *size = 0;
+
+ASSERT((bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
+pci_conf_write32(seg, bus, slot, func, idx, ~0);
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+{
+if ( *index >= max_bars )
+{
+dprintk(XENLOG_WARNING,
+"device %04x:%02x:%02x.%u with 64-bit BAR in last slot\n",
+seg, bus, slot, func);
+return -EINVAL;
+}
+hi = pci_conf_read32(seg, bus, slot, func, idx + 4);
+pci_conf_write32(seg, bus, slot, func, idx + 4, ~0);
+}
+*size = pci_conf_read32(seg, bus, slot, func, idx) &
+PCI_BASE_ADDRESS_MEM_MASK;
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+{
+*size |= (u64)pci_conf_read32(seg, bus, slot, func, idx + 4) << 32;
+pci_conf_write32(seg, bus, slot, func, idx + 4, hi);
+}
+else if ( *size )
+*size |= (u64)~0 << 32;
+pci_conf_write32(seg, bus, slot, func, idx, bar);
+*size = -(*size);
+*addr = (bar & PCI_BASE_ADDRESS_MEM_MASK) | ((u64)hi << 32);
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+++*index;
+
+return 0;
+}
+
 int pci_add_device(u16 seg, u8 bus, u8 devfn,
const struct pci_dev_info *info, nodeid_t node)
 {
@@ -652,7 +697,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 {
 unsigned int idx = pos + PCI_SRIOV_BAR + i * 4;
 u32 bar = pci_conf_read32(seg, bus, slot, func, idx);
-u32 hi = 0;
+uint64_t addr;
 
 if ( (bar & PCI_BASE_ADDRESS_SPACE) ==
  PCI_BASE_ADDRESS_SPACE_IO )
@@ -663,38 +708,13 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
seg, bus, slot, func, i);
 continue;
 }
-pci_conf_write32(seg, bus, slot, func, idx, ~0);
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
-{
-if ( i >= PCI_SRIOV_NUM_BARS )
-{
-printk(XENLOG_WARNING
-   "SR-IOV device %04x:%02x:%02x.%u with 64-bit"
-   " vf BAR in last slot\n",
-   seg, bus, slot, func);
-break;
-}
-hi = pci_conf_read32(seg, bus, slot, func, idx + 4);
-pci_conf_write32(seg, bus, slot, func, idx + 4, ~0);
-}
-pdev->vf_rlen[i] = pci_conf_read32(seg, bus, slot, func, idx) &
-   PCI_BASE_ADDRESS_MEM_MASK;
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
-{
-pdev->vf_rlen[i] |= (u64)pci_conf_read32(seg, bus,
- slot, func,
- idx + 4) << 32;
-pci_conf_write32(seg, bus, slot, func, idx + 4, hi);
-}
-else if ( pdev->vf_rlen[i] )
-pdev->vf_rlen[i] |= (u64)~0 << 32;
-pci_conf_write32(seg, bus, slot, func, idx, bar);
-pdev->vf_rlen[i] = -pdev->vf_rlen[i];
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
-++i;
+ret = pci_size_bar(seg, bus, slot, func, pos + PCI_SRIOV_BAR,
+   PCI_SRIOV_NUM_BARS, &i, &addr,
+   &pdev->vf_rlen[i]);
+if ( ret )
+ 

[Xen-devel] [PATCH v2 for-4.9 4/5] xen/arm: Check if the FDT passed by the bootloader is valid

[Julien Grall]

There is currently no sanity check on the FDT passed by the bootloader.
Whilst they are stricly not necessary, it will avoid us to spend hours
to try to find out why it does not work.

From the booting documentation for AArch32 [1] and AArch64 [2] must :
- be placed on 8-byte boundary
- not exceed 2MB (only on AArch64)

Even if AArch32 does not seem to limit the size, Xen is not currently
able to support more the 2MB FDT. It is better to crash rather with a nice
error message than claiming we are supporting any size of FDT.

The checks are mostly borrowed from the Linux code (see fixmap_remap_fdt
in arch/arm64/mm/mmu.c).

[1] Section 2 in linux/Documentation/arm64/booting.txt
[2] Section 4b in linux/Documentation/arm/Booting

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v2:
- Move the \n from the begining of the last line to the end of
the first line. The 2 \n are here for clarity
- Add missing "."
- Add Stefano's reviewed-by
---
 xen/arch/arm/mm.c   | 29 -
 xen/arch/arm/setup.c|  6 ++
 xen/include/asm-arm/setup.h |  3 +++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 97b3209286..f598396994 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct domain *dom_xen, *dom_io, *dom_cow;
 
@@ -474,11 +476,36 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
 {
 /* We are using 2MB superpage for mapping the FDT */
 paddr_t base_paddr = fdt_paddr & SECOND_MASK;
+paddr_t offset;
+void *fdt_virt;
+
+/*
+ * Check whether the physical FDT address is set and meets the minimum
+ * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
+ * least 8 bytes so that we always access the magic and size fields
+ * of the FDT header after mapping the first chunk, double check if
+ * that is indeed the case.
+ */
+BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
+if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
+return NULL;
+
+/* The FDT is mapped using 2MB superpage */
+BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);
 
 create_mappings(boot_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
 SZ_2M >> PAGE_SHIFT, SZ_2M);
 
-return (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);
+offset = fdt_paddr % SECOND_SIZE;
+fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;
+
+if ( fdt_magic(fdt_virt) != FDT_MAGIC )
+return NULL;
+
+if ( fdt_totalsize(fdt_virt) > MAX_FDT_SIZE )
+return NULL;
+
+return fdt_virt;
 }
 
 void __init remove_early_mappings(void)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 986398970f..e2cda1f134 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -725,6 +725,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 smp_clear_cpu_maps();
 
 device_tree_flattened = early_fdt_map(fdt_paddr);
+if ( !device_tree_flattened )
+panic("Invalid device tree blob at physical address %#lx.\n"
+  "The DTB must be 8-byte aligned and must not exceed 2 MB in 
size.\n\n"
+  "Please check your bootloader.",
+  fdt_paddr);
+
 fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
 
 cmdline = boot_fdt_cmdline(device_tree_flattened);
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 7c761851d2..7ff2c34dab 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,6 +3,9 @@
 
 #include 
 
+#define MIN_FDT_ALIGN 8
+#define MAX_FDT_SIZE SZ_2M
+
 #define NR_MEM_BANKS 64
 
 #define MAX_MODULES 5 /* Current maximum useful modules */
-- 
2.11.0


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

[Xen-devel] [PATCH v2 for-4.9 5/5] xen/arm: Properly map the FDT in the boot page table

[Julien Grall]

Currently, Xen is assuming the FDT will always fit in a 2MB section.
Recently, I noticed an early crash on Xen when using GRUB with the
following call trace:

(XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.9-unstable  arm64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) PC: 00264140 strlen+0x10/0x84
(XEN) LR: 002401c0
(XEN) SP: 002cfc20
(XEN) CPSR:   43c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)  X0: 00801230  X1: 00801230  X2: 5230
(XEN)  X3: 0030  X4: 0030  X5: 0038
(XEN)  X6: 0034  X7:   X8: 7f7f7f7f7f7f7f7f
(XEN)  X9: 64622c6479687222 X10: 7f7f7f7f7f7f7f7f X11: 0101010101010101
(XEN) X12: 0030 X13: ff00ff00 X14: 08000300
(XEN) X15:  X16: fefff610 X17: 00f0
(XEN) X18: 0004 X19: 0008 X20: 007fc040
(XEN) X21: 007fc000 X22: 000e X23: 
(XEN) X24: 002a9f58 X25: 00801230 X26: 002a9f68
(XEN) X27: 002a9f58 X28: 00298910  FP: 002cfc20
(XEN)
(XEN)   VTCR_EL2: 80010c40
(XEN)  VTTBR_EL2: 082800203000
(XEN)
(XEN)  SCTLR_EL2: 30c5183d
(XEN)HCR_EL2: 0038663f
(XEN)  TTBR0_EL2: f4912000
(XEN)
(XEN)ESR_EL2: 9606
(XEN)  HPFAR_EL2: e8071000
(XEN)FAR_EL2: 00801230
(XEN)
(XEN) Xen stack trace from sp=002cfc20:
(XEN)002cfc70 00240254 002a9f58 007fc000
(XEN)   007fc03c
(XEN)002cfd78  002cfca0 002986fc
(XEN) 007fc000  
(XEN)002cfcc0 00298f1c  007fc000
(XEN)002cfdc0 0029904c f47fc000 f4604000
(XEN)f47fc000 007fc000 0040 0100
(XEN)f4604000 0001 0001 8002
(XEN)   
(XEN)   
(XEN)   
(XEN)  002cfdc0 00299038
(XEN)f47fc000 f4604000 f47fc000 
(XEN)002cfe20 0029c420 002d8000 f4604000
(XEN)f47fc000  0040 0100
(XEN)f4604000 0001 f47fc000 0029c404
(XEN)fefff510 00200624 f4804000 f4604000
(XEN)f47fc000  0040 0100
(XEN)0001 0001 0001 8002
(XEN)f47fc000   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN) Xen call trace:
(XEN)[<00264140>] strlen+0x10/0x84 (PC)
(XEN)[<002401c0>] fdt_get_property_namelen+0x9c/0xf0 (LR)
(XEN)[<00240254>] fdt_get_property+0x40/0x50
(XEN)[<002986fc>] bootfdt.c#device_tree_get_u32+0x18/0x5c
(XEN)[<00298f1c>] device_tree_for_each_node+0x84/0x144
(XEN)[<0029904c>] boot_fdt_info+0x70/0x23c
(XEN)[<0029c420>] start_xen+0x9c/0xd30
(XEN)[<00200624>] arm64/head.o#paging+0x84/0xbc
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN)
(XEN) 

Indeed, the booting documentation for AArch32 and AArch64 only requires
the FDT to be placed on a 8-byte boundary. This means the Device-Tree can
cross a 2MB boundary.

Given that Xen limits the size of the FDT to 2MB, it will always fit in
a 4MB slot. So extend the fixmap slot for FDT from 2MB to 4MB.

The second 2MB superpage

[Xen-devel] [PATCH v2 for-4.9 2/5] xen/arm: mm: Move create_mappings function earlier in the file

[Julien Grall]

This function will be called by other function later one. This will
avoid forward declaration and keep the new function close to sibling
ones.

This was moved just after *_fixmap helpers as they are page table
handling functions too.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/mm.c | 68 +++
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f0a2eddaaf..bc65c0e432 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -269,6 +269,40 @@ void clear_fixmap(unsigned map)
 flush_xen_data_tlb_range_va(FIXMAP_ADDR(map), PAGE_SIZE);
 }
 
+/* Create Xen's mappings of memory.
+ * Mapping_size must be either 2MB or 32MB.
+ * Base and virt must be mapping_size aligned.
+ * Size must be a multiple of mapping_size.
+ * second must be a contiguous set of second level page tables
+ * covering the region starting at virt_offset. */
+static void __init create_mappings(lpae_t *second,
+   unsigned long virt_offset,
+   unsigned long base_mfn,
+   unsigned long nr_mfns,
+   unsigned int mapping_size)
+{
+unsigned long i, count;
+const unsigned long granularity = mapping_size >> PAGE_SHIFT;
+lpae_t pte, *p;
+
+ASSERT((mapping_size == MB(2)) || (mapping_size == MB(32)));
+ASSERT(!((virt_offset >> PAGE_SHIFT) % granularity));
+ASSERT(!(base_mfn % granularity));
+ASSERT(!(nr_mfns % granularity));
+
+count = nr_mfns / LPAE_ENTRIES;
+p = second + second_linear_offset(virt_offset);
+pte = mfn_to_xen_entry(base_mfn, WRITEALLOC);
+if ( granularity == 16 * LPAE_ENTRIES )
+pte.pt.contig = 1;  /* These maps are in 16-entry contiguous chunks. */
+for ( i = 0; i < count; i++ )
+{
+write_pte(p + i, pte);
+pte.pt.base += 1 << LPAE_SHIFT;
+}
+flush_xen_data_tlb_local();
+}
+
 #ifdef CONFIG_DOMAIN_PAGE
 void *map_domain_page_global(mfn_t mfn)
 {
@@ -633,40 +667,6 @@ void mmu_init_secondary_cpu(void)
 flush_xen_text_tlb_local();
 }
 
-/* Create Xen's mappings of memory.
- * Mapping_size must be either 2MB or 32MB.
- * Base and virt must be mapping_size aligned.
- * Size must be a multiple of mapping_size.
- * second must be a contiguous set of second level page tables
- * covering the region starting at virt_offset. */
-static void __init create_mappings(lpae_t *second,
-   unsigned long virt_offset,
-   unsigned long base_mfn,
-   unsigned long nr_mfns,
-   unsigned int mapping_size)
-{
-unsigned long i, count;
-const unsigned long granularity = mapping_size >> PAGE_SHIFT;
-lpae_t pte, *p;
-
-ASSERT((mapping_size == MB(2)) || (mapping_size == MB(32)));
-ASSERT(!((virt_offset >> PAGE_SHIFT) % granularity));
-ASSERT(!(base_mfn % granularity));
-ASSERT(!(nr_mfns % granularity));
-
-count = nr_mfns / LPAE_ENTRIES;
-p = second + second_linear_offset(virt_offset);
-pte = mfn_to_xen_entry(base_mfn, WRITEALLOC);
-if ( granularity == 16 * LPAE_ENTRIES )
-pte.pt.contig = 1;  /* These maps are in 16-entry contiguous chunks. */
-for ( i = 0; i < count; i++ )
-{
-write_pte(p + i, pte);
-pte.pt.base += 1 << LPAE_SHIFT;
-}
-flush_xen_data_tlb_local();
-}
-
 #ifdef CONFIG_ARM_32
 /* Set up the xenheap: up to 1GB of contiguous, always-mapped memory. */
 void __init setup_xenheap_mappings(unsigned long base_mfn,
-- 
2.11.0


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

[Xen-devel] [PATCH v2 for-4.9 3/5] xen/arm: Move the code to map FDT in the boot tables from assembly to C

[Julien Grall]

The FDT will not be accessed before start_xen (begining of C code) is
called and it will be easier to maintain as the code could be common
between AArch32 and AArch64.

A new function early_fdt_map is introduced to map the FDT in the boot
page table.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v2:
- Remove the forward declaration for create_mappins as it has
been moved earlier.
- Remove spurious newline.
- Add Stefano's reviewed. I keep it because the change is
minor.
---
 xen/arch/arm/arm32/head.S | 14 --
 xen/arch/arm/arm64/head.S | 13 -
 xen/arch/arm/mm.c | 13 +
 xen/arch/arm/setup.c  |  4 +---
 xen/include/asm-arm/mm.h  |  2 ++
 5 files changed, 16 insertions(+), 30 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index ec63ba4c04..4090f4a744 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -389,20 +389,6 @@ paging:
 /* Use a virtual address to access the UART. */
 ldr   r11, =EARLY_UART_VIRTUAL_ADDRESS
 #endif
-/* Map the DTB in the boot misc slot */
-teq   r12, #0/* Only on boot CPU */
-bne   1f
-
-ldr   r1, =boot_second
-mov   r3, #0x0
-lsr   r2, r8, #SECOND_SHIFT
-lsl   r2, r2, #SECOND_SHIFT  /* r2: 2MB-aligned paddr of DTB */
-orr   r2, r2, #PT_UPPER(MEM)
-orr   r2, r2, #PT_LOWER(MEM) /* r2:r3 := 2MB RAM incl. DTB */
-ldr   r4, =BOOT_FDT_VIRT_START
-mov   r4, r4, lsr #(SECOND_SHIFT - 3)   /* Slot for 
BOOT_FDT_VIRT_START */
-strd  r2, r3, [r1, r4]   /* Map it in the early fdt slot */
-1:
 
 /*
  * Flush the TLB in case the 1:1 mapping happens to clash with
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 72ea4e0233..78292f4396 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -550,19 +550,6 @@ paging:
 ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
 #endif
 
-/* Map the DTB in the boot misc slot */
-cbnz  x22, 1f/* Only on boot CPU */
-
-ldr   x4, =boot_second   /* x4 := vaddr (boot_second) */
-lsr   x2, x21, #SECOND_SHIFT
-lsl   x2, x2, #SECOND_SHIFT  /* x2 := 2MB-aligned paddr of DTB */
-mov   x3, #PT_MEM/* x2 := 2MB RAM incl. DTB */
-orr   x2, x2, x3
-ldr   x1, =BOOT_FDT_VIRT_START
-lsr   x1, x1, #(SECOND_SHIFT - 3)   /* x4 := Slot for 
BOOT_FDT_VIRT_START */
-str   x2, [x4, x1]   /* Map it in the early fdt slot */
-1:
-
 /*
  * Flush the TLB in case the 1:1 mapping happens to clash with
  * the virtual addresses used by the fixmap or DTB.
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index bc65c0e432..97b3209286 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct domain *dom_xen, *dom_io, *dom_cow;
 
@@ -468,6 +469,18 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
 return mfn_to_xen_entry(mfn, WRITEALLOC);
 }
 
+/* Map the FDT in the early boot page table */
+void * __init early_fdt_map(paddr_t fdt_paddr)
+{
+/* We are using 2MB superpage for mapping the FDT */
+paddr_t base_paddr = fdt_paddr & SECOND_MASK;
+
+create_mappings(boot_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
+SZ_2M >> PAGE_SHIFT, SZ_2M);
+
+return (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);
+}
+
 void __init remove_early_mappings(void)
 {
 lpae_t pte = {0};
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 92a2de6b70..986398970f 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -724,9 +724,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 smp_clear_cpu_maps();
 
-/* This is mapped by head.S */
-device_tree_flattened = (void *)BOOT_FDT_VIRT_START
-+ (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
+device_tree_flattened = early_fdt_map(fdt_paddr);
 fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
 
 cmdline = boot_fdt_cmdline(device_tree_flattened);
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 0fef612f42..f6915ad882 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -160,6 +160,8 @@ extern unsigned long total_pages;
 
 /* Boot-time pagetable setup */
 extern void setup_pagetables(unsigned long boot_phys_offset, paddr_t 
xen_paddr);
+/* Map FDT in boot pagetable */
+extern void *early_fdt_map(paddr_t fdt_paddr);
 /* Remove early mappings */
 extern void remove_early_mappings(void);
 /* Allocate and initialise pagetables for a secondary CPU. Sets init_ttbr to 
the
-- 
2.11.0


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

[Xen-devel] [PATCH v2 for-4.9 0/5] xen/arm: Properly map the FDT in the boot page table

[Julien Grall]

Hi,

Whilst doing some testing on Juno using GRUB, I noticed random early crash
depending ([1]) on the binaries I was using.

This is because Xen is assuming that the FDT will always fit in a 2MB
superpage whilst the boot documentation allow the FDT to cross a 2MB boundary.

The first patch move the code that map the FDT in the boot page table from
assembly to C making easier to modify the code.

This series is candidate for Xen 4.9. Whilst this early boot rework sounds
scary, a user can see random early crash without this series. I chose
to move all the FDT mapping code in C right now because it is less error-prone
to write C code than assembly.

I have tested both ARM32 and ARM64 with different position of the FDT without
noticing any issue.

For all the changes see in each patches.

Cheers,

[1]

(XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.9-unstable  arm64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) PC: 00264140 strlen+0x10/0x84
(XEN) LR: 002401c0
(XEN) SP: 002cfc20
(XEN) CPSR:   43c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)  X0: 00801230  X1: 00801230  X2: 5230
(XEN)  X3: 0030  X4: 0030  X5: 0038
(XEN)  X6: 0034  X7:   X8: 7f7f7f7f7f7f7f7f
(XEN)  X9: 64622c6479687222 X10: 7f7f7f7f7f7f7f7f X11: 0101010101010101
(XEN) X12: 0030 X13: ff00ff00 X14: 08000300
(XEN) X15:  X16: fefff610 X17: 00f0
(XEN) X18: 0004 X19: 0008 X20: 007fc040
(XEN) X21: 007fc000 X22: 000e X23: 
(XEN) X24: 002a9f58 X25: 00801230 X26: 002a9f68
(XEN) X27: 002a9f58 X28: 00298910  FP: 002cfc20
(XEN)
(XEN)   VTCR_EL2: 80010c40
(XEN)  VTTBR_EL2: 082800203000
(XEN)
(XEN)  SCTLR_EL2: 30c5183d
(XEN)HCR_EL2: 0038663f
(XEN)  TTBR0_EL2: f4912000
(XEN)
(XEN)ESR_EL2: 9606
(XEN)  HPFAR_EL2: e8071000
(XEN)FAR_EL2: 00801230
(XEN)
(XEN) Xen stack trace from sp=002cfc20:
(XEN)002cfc70 00240254 002a9f58 007fc000
(XEN)   007fc03c
(XEN)002cfd78  002cfca0 002986fc
(XEN) 007fc000  
(XEN)002cfcc0 00298f1c  007fc000
(XEN)002cfdc0 0029904c f47fc000 f4604000
(XEN)f47fc000 007fc000 0040 0100
(XEN)f4604000 0001 0001 8002
(XEN)   
(XEN)   
(XEN)   
(XEN)  002cfdc0 00299038
(XEN)f47fc000 f4604000 f47fc000 
(XEN)002cfe20 0029c420 002d8000 f4604000
(XEN)f47fc000  0040 0100
(XEN)f4604000 0001 f47fc000 0029c404
(XEN)fefff510 00200624 f4804000 f4604000
(XEN)f47fc000  0040 0100
(XEN)0001 0001 0001 8002
(XEN)f47fc000   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN) Xen call trace:
(XEN)[<00264140>] strlen+0x10/0x84 (PC)
(XEN)[<002401c0>] fdt_get_property_namelen+0x9c/0xf0 (LR)
(XEN)[<00240254>] fdt_get_property+0x40/0x50
(XEN)[<002986fc>] bootfdt.c#device_tree_get_u32+0x18/0x5c
(XEN)[<00298f1c>] device_tree_for_each_node+0x84/0x144
(XEN)[<000

[Xen-devel] [PATCH v2 for-4.9 1/5] xen/arm: Add BOOT_FDT_VIRT_END and BOOT_FDT_SLOT_SIZE

[Julien Grall]

The 2 new defines will help to avoid hardcoding the size and the end of
the slot in the code.

The newlines are added for clarity.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/include/asm-arm/config.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index b2edf95f72..9c14a385e7 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -111,7 +111,11 @@
 
 #define XEN_VIRT_START _AT(vaddr_t,0x0020)
 #define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE)
+
 #define BOOT_FDT_VIRT_START_AT(vaddr_t,0x0060)
+#define BOOT_FDT_SLOT_SIZE MB(2)
+#define BOOT_FDT_VIRT_END  (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE)
+
 #define BOOT_RELOC_VIRT_START  _AT(vaddr_t,0x0080)
 #ifdef CONFIG_LIVEPATCH
 #define LIVEPATCH_VMAP_START   _AT(vaddr_t,0x0080)
-- 
2.11.0


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

Re: [Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Peter Zijlstra]

On Thu, Apr 20, 2017 at 03:24:53PM +0200, Vitaly Kuznetsov wrote:
> In this patch I suggest we set __max_logical_packages based on the
> max_physical_pkg_id and total_cpus,

So my 4 socket 144 CPU system will then get max_physical_pkg_id=144,
instead of 4.

This wastes quite a bit of memory for the per-node arrays. Luckily most
are just pointer arrays, but still, wasting 140*8 bytes for each of
them.

> this should be safe and cover all
> possible cases. Alternatively, we may think about eliminating the concept
> of __max_logical_packages completely and relying on max_physical_pkg_id/
> total_cpus where we currently use topology_max_packages().
> 
> The issue could've been solved in Xen too I guess. CPUID returning
> x86_max_cores can be tweaked to be the lowerest(?) possible number of
> all logical packages of the guest.

This is getting ludicrous. Xen is plain broken, and instead of fixing
it, you propose to somehow deal with its obviously crack induced
behaviour :-(


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

Re: [Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Jan Beulich]

>>> On 20.04.17 at 09:37,  wrote:
> On Thu, Apr 20, 2017 at 08:15:49AM -0600, Jan Beulich wrote:
> On 20.04.17 at 08:59,  wrote:
>>> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
>>> On 19.04.17 at 22:22,  wrote:
> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
> and APIC ID are preserved when handling INIT signal and a reset places
> APIC to xAPIC mode and APIC base address to 0xFEE0h (this part
> is in "Local APIC" -> "Local APIC Status and Location"). So there are
> two problems in current code:
> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
> 
> This patch introduces a new function vlapic_do_init() and replaces the
> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
> in vlapic_reset().
> 
> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
> signal in x2APIC mode.
> 
> Signed-off-by: Chao Gao 

Reviewed-by: Jan Beulich 

> I regard this patch as a bug fix. But I haven't seen issues caused by
> this bug and am not sure of the existance of such issues. Anyhow Cc
> Julien and leave the decision to you (Julien and Jan).

Julien,

I'm slightly in favor of taking it now, but I won't object if you decide
otherwise.

Jan
>>> 
>>> I just realize that we also need reset bsp field, otherwise the BSP field
>>> may be cleared in vlapic_reset(). Really Sorry for this. 
>>> 
>>> Jan, do you think this following change is ok? Could you help add this
>>> part when committing? 
>>
>>I could certainly fold it in, but I did indeed think about this bit while
>>reviewing, and I'm not convinced it needs to be kept. Aiui its value
>>is being established (on real hardware) very early using arbitration
>>between CPUs. Forcing the bit on for vCPU0 would probably be in
>>line with the vlapic_reset() use by hvm_s3_suspend(), but I'm
>>rather uncertain about the use in vlapic_msr_set() in this regard.
> 
> I check SDM again. In "MODEL-SPECIFIC REGISTERS" -> "Architechural MSRs",
> we can know the BSP field is R/W. So in vlapic_msr_set(), clearing BSP
> is allowable. In "Advanced Programmable Interrupt Controller" -> "Local APIC"
> -> "Local APIC Status and Location", it says "Following a power-up or reset,
> the flag is set to 1 for the processor selected as the BSP and set to 0 for
> the remaining processors". Which specific problem you think we may have if
> we add this part? I just don't want this patch fixes one bug, incurring
> another.

My primary concern is with the guest possibly offlining its vCPU0.
But having looked again, the additional change you suggested is
benign to vlapic_msr_set(), as the full guest specified value is
being written to vlapic->hw.apic_base_msr soon after the call to
vlapic_reset() anyway. IOW - yes, that addendum should be fine.

Jan


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

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

[osstest service owner]

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

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-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

version targeted for testing:
 xen  f9e2600ea107bf408a2778f456bd1beee29ce3c1
baseline version:
 xen  f97838bbd980a0104e16c4a12fbf514f9fa805f1

Last test of basis   107549  2017-04-19 21:02:37 Z0 days
Testing same since   107563  2017-04-20 13:01:22 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopspass
 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=f9e2600ea107bf408a2778f456bd1beee29ce3c1
+ . ./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 
f9e2600ea107bf408a2778f456bd1beee29ce3c1
+ branch=xen-unstable-smoke
+ revision=f9e2600ea107bf408a2778f456bd1beee29ce3c1
+ . ./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
+ '[' xf9e2600ea107bf408a2778f456bd1beee29ce3c1 = 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/x

Re: [Xen-devel] [PATCH] correct rcu_unlock_domain()

[Jan Beulich]

>>> On 20.04.17 at 16:11,  wrote:
> On 20/04/17 14:48, Jan Beulich wrote:
>> Match rcu_lock_domain(), and remove the slightly misleading comment:
>> This isn't just the companion to rcu_lock_domain_by_id() (and that
>> latter function indeed also keeps the domain locked, not the domain
>> list).
>>
>> No functional change, as rcu_read_{,un}lock() ignore their arguments
>> anyway.

I think the second half of this sentence is ...

>> Reported-by: Jann Horn 
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper , although I think
> it is worth stating in the commit message that the only reason this
> currently works is because rcu_read_unlock() is entirely empty.

.. what you're asking for here: Whether the function is empty is
irrelevant; what is relevant is whether is uses its argument.

Jan


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

Re: [Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Chao Gao]

On Thu, Apr 20, 2017 at 08:15:49AM -0600, Jan Beulich wrote:
 On 20.04.17 at 08:59,  wrote:
>> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
>> On 19.04.17 at 22:22,  wrote:
 According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
 "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
 and APIC ID are preserved when handling INIT signal and a reset places
 APIC to xAPIC mode and APIC base address to 0xFEE0h (this part
 is in "Local APIC" -> "Local APIC Status and Location"). So there are
 two problems in current code:
 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
 2. Forgetting resetting APIC mode and base address in vlapic_reset()
 
 This patch introduces a new function vlapic_do_init() and replaces the
 wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
 in vlapic_reset().
 
 Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
 mode is unreasonable. This patch also doesn't reset LDR when handling INIT
 signal in x2APIC mode.
 
 Signed-off-by: Chao Gao 
>>>
>>>Reviewed-by: Jan Beulich 
>>>
 I regard this patch as a bug fix. But I haven't seen issues caused by
 this bug and am not sure of the existance of such issues. Anyhow Cc
 Julien and leave the decision to you (Julien and Jan).
>>>
>>>Julien,
>>>
>>>I'm slightly in favor of taking it now, but I won't object if you decide
>>>otherwise.
>>>
>>>Jan
>> 
>> I just realize that we also need reset bsp field, otherwise the BSP field
>> may be cleared in vlapic_reset(). Really Sorry for this. 
>> 
>> Jan, do you think this following change is ok? Could you help add this
>> part when committing? 
>
>I could certainly fold it in, but I did indeed think about this bit while
>reviewing, and I'm not convinced it needs to be kept. Aiui its value
>is being established (on real hardware) very early using arbitration
>between CPUs. Forcing the bit on for vCPU0 would probably be in
>line with the vlapic_reset() use by hvm_s3_suspend(), but I'm
>rather uncertain about the use in vlapic_msr_set() in this regard.

I check SDM again. In "MODEL-SPECIFIC REGISTERS" -> "Architechural MSRs",
we can know the BSP field is R/W. So in vlapic_msr_set(), clearing BSP
is allowable. In "Advanced Programmable Interrupt Controller" -> "Local APIC"
-> "Local APIC Status and Location", it says "Following a power-up or reset,
the flag is set to 1 for the processor selected as the BSP and set to 0 for
the remaining processors". Which specific problem you think we may have if
we add this part? I just don't want this patch fixes one bug, incurring
another.

Thanks
Chao

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

Re: [Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

[Julien Grall]

Hi Stefano,

On 19/04/17 22:56, Stefano Stabellini wrote:

On Wed, 19 Apr 2017, Julien Grall wrote:

On 19/04/2017 22:01, Stefano Stabellini wrote:

On Wed, 19 Apr 2017, Julien Grall wrote:

@@ -113,12 +113,12 @@
 #define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE)

 #define BOOT_FDT_VIRT_START_AT(vaddr_t,0x0060)
-#define BOOT_FDT_SLOT_SIZE MB(2)
+#define BOOT_FDT_SLOT_SIZE MB(4)
 #define BOOT_FDT_VIRT_END  (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE)

-#define BOOT_RELOC_VIRT_START  _AT(vaddr_t,0x0080)
+#define BOOT_RELOC_VIRT_START  _AT(vaddr_t,0x00a0)


Wouldn't it be better to define it as BOOT_FDT_VIRT_END?


It is kind of not really related to this patch and how we handle all the
region in config.h today. So if we define in term of *_END this one, then we
need to do it for everyone.


Fair enough


I will prepare a patch for that and send it later on.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Jan Beulich]

>>> On 20.04.17 at 08:59,  wrote:
> On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
> On 19.04.17 at 22:22,  wrote:
>>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>>> and APIC ID are preserved when handling INIT signal and a reset places
>>> APIC to xAPIC mode and APIC base address to 0xFEE0h (this part
>>> is in "Local APIC" -> "Local APIC Status and Location"). So there are
>>> two problems in current code:
>>> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>>> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>>> 
>>> This patch introduces a new function vlapic_do_init() and replaces the
>>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>>> in vlapic_reset().
>>> 
>>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>>> signal in x2APIC mode.
>>> 
>>> Signed-off-by: Chao Gao 
>>
>>Reviewed-by: Jan Beulich 
>>
>>> I regard this patch as a bug fix. But I haven't seen issues caused by
>>> this bug and am not sure of the existance of such issues. Anyhow Cc
>>> Julien and leave the decision to you (Julien and Jan).
>>
>>Julien,
>>
>>I'm slightly in favor of taking it now, but I won't object if you decide
>>otherwise.
>>
>>Jan
> 
> I just realize that we also need reset bsp field, otherwise the BSP field
> may be cleared in vlapic_reset(). Really Sorry for this. 
> 
> Jan, do you think this following change is ok? Could you help add this
> part when committing? 

I could certainly fold it in, but I did indeed think about this bit while
reviewing, and I'm not convinced it needs to be kept. Aiui its value
is being established (on real hardware) very early using arbitration
between CPUs. Forcing the bit on for vCPU0 would probably be in
line with the vlapic_reset() use by hvm_s3_suspend(), but I'm
rather uncertain about the use in vlapic_msr_set() in this regard.

Jan


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

Re: [Xen-devel] [PATCH] correct rcu_unlock_domain()

[Andrew Cooper]

On 20/04/17 14:48, Jan Beulich wrote:
> Match rcu_lock_domain(), and remove the slightly misleading comment:
> This isn't just the companion to rcu_lock_domain_by_id() (and that
> latter function indeed also keeps the domain locked, not the domain
> list).
>
> No functional change, as rcu_read_{,un}lock() ignore their arguments
> anyway.
>
> Reported-by: Jann Horn 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper , although I think
it is worth stating in the commit message that the only reason this
currently works is because rcu_read_unlock() is entirely empty.

>
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -584,11 +584,10 @@ int rcu_lock_remote_domain_by_id(domid_t
>   */
>  int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d);
>  
> -/* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
>  static inline void rcu_unlock_domain(struct domain *d)
>  {
>  if ( d != current->domain )
> -rcu_read_unlock(&domlist_read_lock);
> +rcu_read_unlock(d);
>  }
>  
>  static inline struct domain *rcu_lock_domain(struct domain *d)
>
>
>


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

Re: [Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Chao Gao]

On Thu, Apr 20, 2017 at 07:34:30AM -0600, Jan Beulich wrote:
 On 19.04.17 at 22:22,  wrote:
>> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
>> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
>> and APIC ID are preserved when handling INIT signal and a reset places
>> APIC to xAPIC mode and APIC base address to 0xFEE0h (this part
>> is in "Local APIC" -> "Local APIC Status and Location"). So there are
>> two problems in current code:
>> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
>> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
>> 
>> This patch introduces a new function vlapic_do_init() and replaces the
>> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
>> in vlapic_reset().
>> 
>> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
>> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
>> signal in x2APIC mode.
>> 
>> Signed-off-by: Chao Gao 
>
>Reviewed-by: Jan Beulich 
>
>> I regard this patch as a bug fix. But I haven't seen issues caused by
>> this bug and am not sure of the existance of such issues. Anyhow Cc
>> Julien and leave the decision to you (Julien and Jan).
>
>Julien,
>
>I'm slightly in favor of taking it now, but I won't object if you decide
>otherwise.
>
>Jan

I just realize that we also need reset bsp field, otherwise the BSP field
may be cleared in vlapic_reset(). Really Sorry for this. 

Jan, do you think this following change is ok? Could you help add this
part when committing? 

Thanks
Chao

---8<---
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 4ac9f46..cf8ee50 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1290,6 +1290,8 @@ void vlapic_reset(struct vlapic *vlapic)
 
 vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
 APIC_DEFAULT_PHYS_BASE);
+if ( v->vcpu_id == 0 )
+vlapic->hw.apic_base_msr |= MSR_IA32_APICBASE_BSP;
 
 vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
 vlapic_do_init(vlapic);
@@ -1509,9 +1511,6 @@ int vlapic_init(struct vcpu *v)
 
 vlapic_reset(vlapic);
 
-if ( v->vcpu_id == 0 )
-vlapic->hw.apic_base_msr |= MSR_IA32_APICBASE_BSP;
-
 spin_lock_init(&vlapic->esr_lock);
 
 tasklet_init(&vlapic->init_sipi.tasklet,

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

[Xen-devel] [PATCH] correct rcu_unlock_domain()

[Jan Beulich]

Match rcu_lock_domain(), and remove the slightly misleading comment:
This isn't just the companion to rcu_lock_domain_by_id() (and that
latter function indeed also keeps the domain locked, not the domain
list).

No functional change, as rcu_read_{,un}lock() ignore their arguments
anyway.

Reported-by: Jann Horn 
Signed-off-by: Jan Beulich 

--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -584,11 +584,10 @@ int rcu_lock_remote_domain_by_id(domid_t
  */
 int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d);
 
-/* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
 if ( d != current->domain )
-rcu_read_unlock(&domlist_read_lock);
+rcu_read_unlock(d);
 }
 
 static inline struct domain *rcu_lock_domain(struct domain *d)



correct rcu_unlock_domain()

Match rcu_lock_domain(), and remove the slightly misleading comment:
This isn't just the companion to rcu_lock_domain_by_id() (and that
latter function indeed also keeps the domain locked, not the domain
list).

No functional change, as rcu_read_{,un}lock() ignore their arguments
anyway.

Reported-by: Jann Horn 
Signed-off-by: Jan Beulich 

--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -584,11 +584,10 @@ int rcu_lock_remote_domain_by_id(domid_t
  */
 int rcu_lock_live_remote_domain_by_id(domid_t dom, struct domain **d);
 
-/* Finish a RCU critical region started by rcu_lock_domain_by_id(). */
 static inline void rcu_unlock_domain(struct domain *d)
 {
 if ( d != current->domain )
-rcu_read_unlock(&domlist_read_lock);
+rcu_read_unlock(d);
 }
 
 static inline struct domain *rcu_lock_domain(struct domain *d)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Jan Beulich]

>>> On 19.04.17 at 22:22,  wrote:
> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
> and APIC ID are preserved when handling INIT signal and a reset places
> APIC to xAPIC mode and APIC base address to 0xFEE0h (this part
> is in "Local APIC" -> "Local APIC Status and Location"). So there are
> two problems in current code:
> 1. Using reset logic (aka vlapic_reset) to handle INIT signal.
> 2. Forgetting resetting APIC mode and base address in vlapic_reset()
> 
> This patch introduces a new function vlapic_do_init() and replaces the
> wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
> in vlapic_reset().
> 
> Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
> mode is unreasonable. This patch also doesn't reset LDR when handling INIT
> signal in x2APIC mode.
> 
> Signed-off-by: Chao Gao 

Reviewed-by: Jan Beulich 

> I regard this patch as a bug fix. But I haven't seen issues caused by
> this bug and am not sure of the existance of such issues. Anyhow Cc
> Julien and leave the decision to you (Julien and Jan).

Julien,

I'm slightly in favor of taking it now, but I won't object if you decide
otherwise.

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Eric Blake]

On 04/20/2017 06:59 AM, Markus Armbruster wrote:

> 
> No objection to Alistair's idea to turn this into an enumeration.

Question - should the enum be more than just 'guest' and 'host'?  For
example, my patch proves that we have a lot of places that handle
complimentary machine commands to reset and shutdown, and that whether
'reset' triggers a reset (and the guest keeps running as if rebooted) or
a shutdown is then based on the command-line arguments given to qemu.
So having the enum differentiate between 'guest-reset' and
'guest-shutdown' would be a possibility, if we want the enum to have
additional states.


>> +++ b/vl.c
>> @@ -1717,7 +1717,7 @@ void qemu_system_guest_panicked(GuestPanicInformation 
>> *info)
>>  if (!no_shutdown) {
>>  qapi_event_send_guest_panicked(GUEST_PANIC_ACTION_POWEROFF,
>> !!info, info, &error_abort);
>> -qemu_system_shutdown_request();
>> +qemu_system_shutdown_request(false);
> 
> Panicking is a guest action.  Whether the shutdown on panic should be
> attributed to guest or host is perhaps debatable.

And it relates to the idea that a guest request for a 'reset' turns into
a qemu response of 'shutdown'.  After all, whether a guest panic results
in a shutdown action is determined by command-line arguments to qemu.
So if we DO want to differentiate between a guest panic and a normal
guest shutdown, when both events are wired at the command line to cause
the SHUTDOWN action, then that's another enum to add to my list.


>> +++ b/replay/replay.c
>> @@ -51,7 +51,10 @@ bool replay_next_event_is(int event)
>>  switch (replay_state.data_kind) {
>>  case EVENT_SHUTDOWN:
>>  replay_finish_event();
>> -qemu_system_shutdown_request();
>> +/* TODO: track source of shutdown request, to replay a
>> + * guest-initiated request rather than always claiming to
>> + * be from the host? */
>> +qemu_system_shutdown_request(false);
> 
> This is what your "need a followup patch" refers to.  I'd like to have
> an opinion from someone familiar with replay on what exactly we need
> here.

replay-internal.h has an enum ReplayEvents, which is a list of one-byte
codes used in the replay data stream to record which event to replay. I
don't know if it is easier to change the replay stream to add a 2-byte
code (shutdown-with-cause, followed by an encoding of the cause enum),
or a range of one-byte codes (one new code per number of enum members).
I also don't know how easy or hard it is to extend the enum (are we free
to add events in the middle, or are we worried about back-compat to an
older replay stream that must still play correctly with a newer qemu,
such that new events must be higher than all existing events).

So yes, I'm hoping for feedback from someone familiar with replay.

> 
> Amazing number of ways to shut down or reset a machine.

And as I said, it would be easier to submit a patch with less churn by
having the uncommon case (host-triggered) call a new
qemu_system_shutdown_request_reason(enum), while the common case
(guest-triggered) be handled by having qemu_system_shutdown_request()
with no arguments call
qemu_system_shutdown_request_reason(SHUTDOWN_GUEST).  I'm just worried
that doing it that way makes it easy for yet another new host shutdown
method to use the wrong wrapper.

> 
> Looks sane on first glance.
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

[Xen-devel] [PATCH RFC] x86/smpboot: Set safer __max_logical_packages limit

[Vitaly Kuznetsov]

Recent changes in logical package management (Commit 9d85eb9119f4
("x86/smpboot: Make logical package management more robust") and its
predecessor) caused boot failures for some Xen guests. E.g. I'm trying to
boot 10 CPU guest on AMD Opteron 4284 system and I see the following crash:

[0.116104] smpboot: Max logical packages: 1
...
[0.590068]   #8
[0.001000] smpboot: Package 1 of CPU 8 exceeds BIOS package data 1.
[0.001000] [ cut here ]
[0.001000] kernel BUG at arch/x86/kernel/cpu/common.c:1020!

This is happening because total_cpus is 10 and x86_max_cores is 16(!).
Turns out, the number of CPUs (vCPUs in our case) in each logical package
doesn't have to be exactly x86_max_cores, we can have any number of CPUs
<= x86_max_cores and they also don't have to match for all logical
packages. This breaks the current concept of __max_logical_packages.

In this patch I suggest we set __max_logical_packages based on the
max_physical_pkg_id and total_cpus, this should be safe and cover all
possible cases. Alternatively, we may think about eliminating the concept
of __max_logical_packages completely and relying on max_physical_pkg_id/
total_cpus where we currently use topology_max_packages().

The issue could've been solved in Xen too I guess. CPUID returning
x86_max_cores can be tweaked to be the lowerest(?) possible number of
all logical packages of the guest.

Fixes: 9d85eb9119f4 ("x86/smpboot: Make logical package management more robust")
Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/kernel/smpboot.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index bd1f1ad..85f41cd 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -359,7 +359,6 @@ static void __init smp_init_package_map(struct cpuinfo_x86 
*c, unsigned int cpu)
ncpus = 1;
}
 
-   __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
logical_packages = 0;
 
/*
@@ -367,6 +366,15 @@ static void __init smp_init_package_map(struct cpuinfo_x86 
*c, unsigned int cpu)
 * package can be smaller than the actual used apic ids.
 */
max_physical_pkg_id = DIV_ROUND_UP(MAX_LOCAL_APIC, ncpus);
+
+   /*
+* Each logical package has not more than x86_max_cores CPUs but
+* it can happen that it has less, e.g. we may have 1 CPU per logical
+* package regardless of what's in x86_max_cores. This is seen on some
+* Xen setups with AMD processors.
+*/
+   __max_logical_packages = min(max_physical_pkg_id, total_cpus);
+
size = max_physical_pkg_id * sizeof(unsigned int);
physical_to_logical_pkg = kmalloc(size, GFP_KERNEL);
memset(physical_to_logical_pkg, 0xff, size);
-- 
2.9.3


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

Re: [Xen-devel] [PATCH] x86/microcode: Use the return value from early_microcode_update_cpu

[Andrew Cooper]

On 20/04/17 14:18, Ross Lagerwall wrote:
> Use the return value from early_microcode_update_cpu rather than
> ignoring it.

Spotted by Coverity.

>
> Signed-off-by: Ross Lagerwall 

Reviewed-by: Andrew Cooper 

Julien, can we have a release ack please?

~Andrew

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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Jan Beulich]

>>> On 20.04.17 at 15:02,  wrote:
>> On 20 Apr 2017, at 10:43, Jan Beulich  wrote:
>> 
> On 20.04.17 at 04:14,  wrote:
>>> On 17-04-19 03:00:29, Jan Beulich wrote:
>>> On 19.04.17 at 10:22,  wrote:
> On 17-04-18 05:46:43, Jan Beulich wrote:
> On 18.04.17 at 12:55,  wrote:
>>> I made a test patch based on v10 and attached it in mail. Could you 
>>> please
>>> help to check it? Thanks!
>> 
>> This looks reasonable at the first glance, albeit I continue to be
>> unconvinced that this is the only (reasonable) way of solving the
>>> 
>>> Do you have any other suggestion on this? Thanks!
>> 
>> I'm sorry, but no. I'm already spending _much_ more time on this
>> series than I should be, considering its (afaic) relatively low
>> priority. I really have to ask you to properly think through both
>> the data layout and code structure, including considering
>> alternatives especially in places where you can _anticipate_
>> controversy.
> 
> Jan, can you confirm whether you are happy with the current proposal. You 
> say "this looks reasonable at the first glance", but then go on to say that 
> there may be other "reasonable ways" of solving the problem at hand.
> 
> This is not very concrete and hard to respond to from a contributors point 
> of view: it would be good to establish whether a) the v10 proposal in this 
> area is good enough, b) whether there are any concrete improvements to be 
> made.

I understand it's not very concrete, but please understand that with
the over 100 patches wanting looking at right now it is simply
impossible for me to give precise suggestions everywhere. I really
have to be allowed to defer to the originator to come up with
possible better mechanisms (or defend what there is by addressing
questions raised), especially with - as said - the amount of time spent
here already having been way higher than is justifiable. Just go and
compare v10 with one of the initial versions: Almost all of the data
layout and code flow have fundamentally changed, mostly based on
feedback I gave. I'm sorry for saying that, but to me this is an
indication that things hadn't been thought through well in the design
phase, i.e. before even submitting a first RFC.

> You say please think through whether "you can _anticipate_ controversy", but 
> at the same time you can't currently identify/think of any issues. That seems 
> to suggest to me that maybe the proposal is good enough. Or that something is 
> missing, which has not been articulated. Taking into account language 
> barriers, more clarity would probably be helpful.

I've given criteria by which I have the gut feeling (but no more)
that this isn't the right approach. I'm absolutely fine to be
convinced that my gut feeling is wrong. That would require to
simply answer the question I raised multiple times, and which was
repeatedly "answered" by simply re-stating previously expressed
facts.

If this reaction of mine is not acceptable, all I can do is refrain
from further looking at this series. And Yi, I certainly apologize
for perhaps not doing these reviews wholeheartedly, since -
as also expressed before - I continue to not really view this as
very important functionality. Yet considering for how long some
of the versions hadn't been looked at by anyone at all, the
alternative would have been to simply let it sit further without
looking at it. I actually take this lack of interest by others as an
indication that I'm not the only one considering this nice to have,
but no more.

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Eric Blake]

On 04/20/2017 07:09 AM, Daniel P. Berrange wrote:

>>> +++ b/qapi/event.json
>>> @@ -10,6 +10,10 @@
>>>  # Emitted when the virtual machine has shut down, indicating that qemu is
>>>  # about to exit.
>>>  #
>>> +# @guest: If true, the shutdown was triggered by a guest request (such as
>>> +# executing a halt instruction) rather than a host request (such as sending
>>> +# qemu a SIGINT). (since 2.10)
>>> +#
>>
>> "executing a halt instruction" suggests "halt" is a machine instruction.

Which is indeed what most of the places I patched to pass 'true' are
emulating - the machine halt instruction.

>> I think you mean /usr/sbin/halt.  Suggest something like "executing a
>> halt command".
> 
> Well technically /usr/sbin/halt just terminates all processes / kernel and
> halts CPUs, but the virtual machine is still active (and a 'reset' in the
> monitor can start it again. /usr/sbin/poweroff is what actually does the
> ACPI poweroff to trigger QEMU to exit[1]

I'm thinking of this wording:

triggered by a guest request (such as the guest running
/usr/sbin/poweroff to trigger an ACPI shutdown or machine halt instruction)


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

[Xen-devel] [PATCH] x86/microcode: Use the return value from early_microcode_update_cpu

[Ross Lagerwall]

Use the return value from early_microcode_update_cpu rather than
ignoring it.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/microcode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 4e7dfcd..7558202 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -431,5 +431,5 @@ int __init early_microcode_init(void)
 register_cpu_notifier(µcode_percpu_nfb);
 }
 
-return 0;
+return rc;
 }
-- 
2.7.4


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

Re: [Xen-devel] [xen-unstable test] 107553: regressions - FAIL

[Andrew Cooper]

On 20/04/17 13:18, osstest service owner wrote:
> flight 107553 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/107553/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-xsm   5 xen-buildfail REGR. vs. 
> 107539

make[7]: Entering directory 
'/home/osstest/build.107553.build-amd64-xsm/xen/tools/firmware/seabios-dir-remote'
/bin/bash ../libtool --mode=link gcc  -mno-red-zone -O1 -fno-omit-frame-pointer 
-O1 -fno-omit-frame-pointer  -m64 -mno-red-zone -fno-reorder-blocks 
-fno-asynchronous-unwind-tables -m64 -DBUILD_ID -fno-strict-aliasing -std=gnu99 
-Wall -Wstrict-prototypes -Wdeclaration-after-statement 
-Wno-unused-but-set-variable -Wno-unused-local-typedefs   -fno-stack-protector 
-fno-exceptions   -o libmpq.la   abs.lo aors.lo canonicalize.lo clear.lo cmp.lo 
cmp_si.lo cmp_ui.lo div.lo equal.lo get_d.lo get_den.lo get_num.lo get_str.lo 
init.lo inp_str.lo inv.lo md_2exp.lo mul.lo neg.lo out_str.lo set.lo set_den.lo 
set_num.lo set_si.lo set_str.lo set_ui.lo set_z.lo set_d.lo set_f.lo swap.lo  
mkdir .libs
  Compiling to assembler out/src/asm-offsets.s
src/asm-offsets.c:1:0: fatal error: can't open out/src/asm-offsets.s for 
writing: No such file or directory
 // Generate assembler offsets.
 ^
compilation terminated.
make[8]: Entering directory 
'/home/osstest/build.107553.build-amd64-xsm/xen/tools/firmware/seabios-dir-remote'
make[8]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
Makefile:130: recipe for target 'out/src/asm-offsets.s' failed
The bug is not reproducible, so it is likely a hardware or OS problem.
make[7]: *** [out/src/asm-offsets.s] Error 1
make[7]: *** Waiting for unfinished jobs


I take issue with the conclusion drawn.  Sounds like there is a makefile
race condition in SeaBIOS.

~Andrew

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

[Xen-devel] [PATCH 1/2] sg-report-flight: Do not try to print nonexistent FirstTip info

[Ian Jackson]

The use of $info->{FirstTip}{flight} autovivifies $info->{FirstTip}.
Defend $pinfo against the use of an autovivified empty hashref.

Signed-off-by: Ian Jackson 
---
 sg-report-flight |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sg-report-flight b/sg-report-flight
index 7d2bc66..5b8f67a 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -586,7 +586,7 @@ sub print_pushgate_summary () {
my $f = $info->{$flightkey};
my $count = $info->{$countkey};
bodyprintf "%-20s", $what;
-   if ($f) {
+   if ($f && %$f) {
bodyprintf(" %6d  %s %4d days",
   $f->{flight},
   show_abs_time($f->{started}),
-- 
1.7.10.4


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

[Xen-devel] [PATCH 2/2] sg-report-flight: Do not report many non-regressions as allowable

[Ian Jackson]

In bd648aea2ebe
 sg-report-flight: report allowable regressions separately in summary
whether the regression was allowable was put in $allow, but this
was erroneously not used.

In 4a210cda9cc8
 sg-report-flight: fix allowable failure logic not to reuse $allow for two 
purposes (!)
that use of the variable, which was never used, was removed.

However, what ought to happen, is that $failv->{Allow} would be set to
1 if the entry matched an allow pattern, and only if it was a blocker.
That makes the logic in "report ... separately" correct.

Signed-off-by: Ian Jackson 
---
 sg-report-flight |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sg-report-flight b/sg-report-flight
index 5b8f67a..5e362b9 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -888,6 +888,7 @@ END
 print DEBUG " allow $item?";
 foreach my $allowpat (@allows) {
 next unless $item =~ m/$allowpat/;
+$failv->{Allow}= 1;
 $blocker='';
 print DEBUG " allowed";
 last;
@@ -895,7 +896,6 @@ END
 print DEBUG "\n";
 }
$failv->{Blocker}= $blocker;
-$failv->{Allow}= 1;
$failv->{SummaryCore}= $rtups[0][2];
$failv->{SummaryRefFlight}= $rtups[0][3];
$failv->{Summary}= $failv->{SummaryCore};
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Lars Kurth]

Apologies for stepping in here. But it feels to me that this thread is at risk 
of becoming unproductive.

> On 20 Apr 2017, at 10:43, Jan Beulich  wrote:
> 
 On 20.04.17 at 04:14,  wrote:
>> On 17-04-19 03:00:29, Jan Beulich wrote:
>> On 19.04.17 at 10:22,  wrote:
 On 17-04-18 05:46:43, Jan Beulich wrote:
 On 18.04.17 at 12:55,  wrote:
>> I made a test patch based on v10 and attached it in mail. Could you 
>> please
>> help to check it? Thanks!
> 
> This looks reasonable at the first glance, albeit I continue to be
> unconvinced that this is the only (reasonable) way of solving the
>> 
>> Do you have any other suggestion on this? Thanks!
> 
> I'm sorry, but no. I'm already spending _much_ more time on this
> series than I should be, considering its (afaic) relatively low
> priority. I really have to ask you to properly think through both
> the data layout and code structure, including considering
> alternatives especially in places where you can _anticipate_
> controversy.

Jan, can you confirm whether you are happy with the current proposal. You say 
"this looks reasonable at the first glance", but then go on to say that there 
may be other "reasonable ways" of solving the problem at hand.

This is not very concrete and hard to respond to from a contributors point of 
view: it would be good to establish whether a) the v10 proposal in this area is 
good enough, b) whether there are any concrete improvements to be made.

You say please think through whether "you can _anticipate_ controversy", but at 
the same time you can't currently identify/think of any issues. That seems to 
suggest to me that maybe the proposal is good enough. Or that something is 
missing, which has not been articulated. Taking into account language barriers, 
more clarity would probably be helpful.

>> Per our discussion on v9 patch 05, we decided to adopt option 2. Below are
>> what we discussed. FYR.
> 
> Well, we decided option 2 is better than option 1. I'm still
> unconvinced there's not a yet better alternative.

I suppose that is the same type of argument. Aka we looked at a number of 
options, seem to have agreed one is better than the other. But there is no 
clarity as to whether in this case option 2 is good enough and what concrete 
steps would be needed to get to a better alternative.

Of course I may have missed some of the context here in some of the older 
threads and thus I may have missed some of the context. 

>> If it is not 0 which means the domain's cos id does not need restore
>> to 0, we can directly set it into ASSOC register. That can avoid
>> unnecessary lock. I will send out the test patch again to ask your
>> help to provide review comments (you said there are also 'a number
>> of cosmetics issues').
> 
> And I would hope you would try to eliminate some (if not all) yourself
> first. After all you can easily go over your patch yourself, checking
> for e.g. style violations.

I think this is fair enough.

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

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

[Julien Grall]

Hi Stefano,

On 19/04/17 22:18, Stefano Stabellini wrote:

On Wed, 19 Apr 2017, Julien Grall wrote:

On 19/04/2017 22:01, Stefano Stabellini wrote:

On Wed, 19 Apr 2017, Julien Grall wrote:
I would have added early_fdt_map to this file in a way to avoid the need
for duplicating the declaration of create_mappings (because this version
doesn't have the useful comment on top).


I wanted to keep the function close to the counterpart remove_early_mappings
rather than adding somewhere that make less sense.

Hence why I suggested to move the create_mappings function. Would you be fine
with code motion for Xen 4.9?


Sure. But please keep the code motion in its own separate patch.


I was planning to do the code motion in a separate patch :). My concern 
was to shuffle the code unnecessarily during code freeze and was 
planning to do it after the freeze.


Anyway, I will resend this series with a patch to move the function.

Cheers,

--
Julien Grall

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