Re: [Xen-devel] [PATCH v2 1/6] x86/xpti: avoid copying L4 page table contents when possible

[Jan Beulich]

>>> On 06.03.18 at 08:01,  wrote:
> On 05/03/18 17:43, Jan Beulich wrote:
> On 02.03.18 at 09:13,  wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -509,6 +509,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>>  
>>>  void write_ptbase(struct vcpu *v)
>>>  {
>>> +get_cpu_info()->root_pgt_changed = this_cpu(root_pgt) && is_pv_vcpu(v) 
>>> &&
>>> +   !is_pv_32bit_vcpu(v);
>> 
>> Why is_pv_vcpu() when you already check is_pv_32bit_vcpu()?
> 
> I check !is_pv_32bit_vcpu() to catch 64-bit pv-domains only.

Oh, I'm sorry - For whatever reason I've ignored the ! there.

>> And don't you need to disallow updating L4s of running guests now
>> (which is a bad idea anyway)?
> 
> Yes, I should do that.

But please do this as a separate change, as strictly speaking this is
a behavioral change that we can't allow. But I think we simply need
to accept this (and perhaps uniformly for all page table levels).

Jan


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

Re: [Xen-devel] [PATCH 8/9] drm/xen-front: Implement GEM operations

[Oleksandr Andrushchenko]

On 03/06/2018 09:26 AM, Daniel Vetter wrote:

On Mon, Mar 05, 2018 at 03:46:07PM +0200, Oleksandr Andrushchenko wrote:

On 03/05/2018 11:32 AM, Daniel Vetter wrote:

On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment, namely
requirements dictated by the accompanying DRM/(v)GPU drivers running in both
host and guest environments, number of operating modes of para-virtualized
display driver are supported:
   - display buffers can be allocated by either frontend driver or backend
   - display buffers can be allocated to be contiguous in memory or not

Note! Frontend driver itself has no dependency on contiguous memory for
its operation.

1. Buffers allocated by the frontend driver.

The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.

1.1. Front driver configured to use GEM CMA helpers
   This use-case is useful when used with accompanying DRM/vGPU driver in
   guest domain which was designed to only work with contiguous buffers,
   e.g. DRM driver based on GEM CMA helpers: such drivers can only import
   contiguous PRIME buffers, thus requiring frontend driver to provide
   such. In order to implement this mode of operation para-virtualized
   frontend driver can be configured to use GEM CMA helpers.

1.2. Front driver doesn't use GEM CMA
   If accompanying drivers can cope with non-contiguous memory then, to
   lower pressure on CMA subsystem of the kernel, driver can allocate
   buffers from system memory.

Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.

2. Buffers allocated by the backend

This mode of operation is run-time configured via guest domain configuration
through XenStore entries.

For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
physically contiguous memory, this allows implementing zero-copying
use-cases.

Note! Configuration options 1.1 (contiguous display buffers) and 2 (backend
allocated buffers) are not supported at the same time.

Signed-off-by: Oleksandr Andrushchenko 

Some suggestions below for some larger cleanup work.
-Daniel


---
   drivers/gpu/drm/xen/Kconfig |  13 +
   drivers/gpu/drm/xen/Makefile|   6 +
   drivers/gpu/drm/xen/xen_drm_front.h |  74 ++
   drivers/gpu/drm/xen/xen_drm_front_drv.c |  80 ++-
   drivers/gpu/drm/xen/xen_drm_front_drv.h |   1 +
   drivers/gpu/drm/xen/xen_drm_front_gem.c | 360 

   drivers/gpu/drm/xen/xen_drm_front_gem.h |  46 
   drivers/gpu/drm/xen/xen_drm_front_gem_cma.c |  93 +++
   8 files changed, 667 insertions(+), 6 deletions(-)
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.c
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.h
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c

diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
index 4cca160782ab..4f4abc91f3b6 100644
--- a/drivers/gpu/drm/xen/Kconfig
+++ b/drivers/gpu/drm/xen/Kconfig
@@ -15,3 +15,16 @@ config DRM_XEN_FRONTEND
help
  Choose this option if you want to enable a para-virtualized
  frontend DRM/KMS driver for Xen guest OSes.
+
+config DRM_XEN_FRONTEND_CMA
+   bool "Use DRM CMA to allocate dumb buffers"
+   depends on DRM_XEN_FRONTEND
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   help
+ Use DRM CMA helpers to allocate display buffers.
+ This is useful for the use-cases when guest driver needs to
+ share or export buffers to other drivers which only expect
+ contiguous buffers.
+ Note: in this mode driver cannot use buffers allocated
+ by the backend.
diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
index 4fcb0da1a9c5..12376ec78fbc 100644
--- a/drivers/gpu/drm/xen/Makefile
+++ b/drivers/gpu/drm/xen/Makefile
@@ -8,4 +8,10 @@ drm_xen_front-objs := xen_drm_front.o \
  xen_drm_front_shbuf.o \
  xen_drm_front_cfg.o
+ifeq ($(CONFIG_DRM_XEN_FRONTEND_CMA),y)
+   drm_xen_front-objs += xen_drm_front_gem_cma.o
+else
+   drm_xen_front-objs += xen_drm_front_gem.o
+endif
+
   obj-$(CONFIG_DRM_XEN_FRONTEND) += drm_xen_front.o
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h 
b/drivers/gpu/drm/xen/xen_drm_front.h
index 9ed5bfb248d0..c6f52c892434 100644
--- a/drivers/gpu/drm/xen/xen_drm_front

Re: [Xen-devel] [PATCH 7/9] drm/xen-front: Implement KMS/connector handling

[Oleksandr Andrushchenko]

On 03/06/2018 09:22 AM, Daniel Vetter wrote:

On Mon, Mar 05, 2018 at 02:59:23PM +0200, Oleksandr Andrushchenko wrote:

On 03/05/2018 11:23 AM, Daniel Vetter wrote:

On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:

- implement KMS part of the driver with the help of DRM
simple pipepline helper which is possible due to the fact
that the para-virtualized driver only supports a single
(primary) plane:
- initialize connectors according to XenStore configuration
- handle frame done events from the backend
- generate vblank events
- create and destroy frame buffers and propagate those
  to the backend
- propagate set/reset mode configuration to the backend on display
  enable/disable callbacks
- send page flip request to the backend and implement logic for
  reporting backend IO errors on prepare fb callback

- implement virtual connector handling:
- support only pixel formats suitable for single plane modes
- make sure the connector is always connected
- support a single video mode as per para-virtualized driver
  configuration

Signed-off-by: Oleksandr Andrushchenko 

I think once you've removed the midlayer in the previous patch it would
makes sense to merge the 2 patches into 1.

ok, will squash the two

Bunch more comments below.
-Daniel


---
   drivers/gpu/drm/xen/Makefile |   2 +
   drivers/gpu/drm/xen/xen_drm_front_conn.c | 125 +
   drivers/gpu/drm/xen/xen_drm_front_conn.h |  35 
   drivers/gpu/drm/xen/xen_drm_front_drv.c  |  15 ++
   drivers/gpu/drm/xen/xen_drm_front_drv.h  |  12 ++
   drivers/gpu/drm/xen/xen_drm_front_kms.c  | 299 
+++
   drivers/gpu/drm/xen/xen_drm_front_kms.h  |  30 
   7 files changed, 518 insertions(+)
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.c
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.h
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.c
   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.h

diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
index d3068202590f..4fcb0da1a9c5 100644
--- a/drivers/gpu/drm/xen/Makefile
+++ b/drivers/gpu/drm/xen/Makefile
@@ -2,6 +2,8 @@
   drm_xen_front-objs := xen_drm_front.o \
  xen_drm_front_drv.o \
+ xen_drm_front_kms.o \
+ xen_drm_front_conn.o \
  xen_drm_front_evtchnl.o \
  xen_drm_front_shbuf.o \
  xen_drm_front_cfg.o
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c 
b/drivers/gpu/drm/xen/xen_drm_front_conn.c
new file mode 100644
index ..d9986a2e1a3b
--- /dev/null
+++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
@@ -0,0 +1,125 @@
+/*
+ *  Xen para-virtual DRM device
+ *
+ *   This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *   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.
+ *
+ * Copyright (C) 2016-2018 EPAM Systems Inc.
+ *
+ * Author: Oleksandr Andrushchenko 
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "xen_drm_front_conn.h"
+#include "xen_drm_front_drv.h"
+
+static struct xen_drm_front_drm_pipeline *
+to_xen_drm_pipeline(struct drm_connector *connector)
+{
+   return container_of(connector, struct xen_drm_front_drm_pipeline, conn);
+}
+
+static const uint32_t plane_formats[] = {
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_ARGB1555,
+};
+
+const uint32_t *xen_drm_front_conn_get_formats(int *format_count)
+{
+   *format_count = ARRAY_SIZE(plane_formats);
+   return plane_formats;
+}
+
+static enum drm_connector_status connector_detect(
+   struct drm_connector *connector, bool force)
+{
+   if (drm_dev_is_unplugged(connector->dev))
+   return connector_status_disconnected;
+
+   return connector_status_connected;
+}
+
+#define XEN_DRM_NUM_VIDEO_MODES1
+#define XEN_DRM_CRTC_VREFRESH_HZ   60
+
+static int connector_get_modes(struct drm_connector *connector)
+{
+   struct xen_drm_front_drm_pipeline *pipeline =
+   to_xen_drm_pipeline(connector);
+   struct drm_display_mode *mode;
+   struct videomode videomode;
+   int width, height;
+
+   mode = drm_mode_create(connector->dev);
+

Re: [Xen-devel] [PATCH 8/9] drm/xen-front: Implement GEM operations

[Daniel Vetter]

On Mon, Mar 05, 2018 at 03:46:07PM +0200, Oleksandr Andrushchenko wrote:
> On 03/05/2018 11:32 AM, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko 
> > > 
> > > Implement GEM handling depending on driver mode of operation:
> > > depending on the requirements for the para-virtualized environment, namely
> > > requirements dictated by the accompanying DRM/(v)GPU drivers running in 
> > > both
> > > host and guest environments, number of operating modes of para-virtualized
> > > display driver are supported:
> > >   - display buffers can be allocated by either frontend driver or backend
> > >   - display buffers can be allocated to be contiguous in memory or not
> > > 
> > > Note! Frontend driver itself has no dependency on contiguous memory for
> > > its operation.
> > > 
> > > 1. Buffers allocated by the frontend driver.
> > > 
> > > The below modes of operation are configured at compile-time via
> > > frontend driver's kernel configuration.
> > > 
> > > 1.1. Front driver configured to use GEM CMA helpers
> > >   This use-case is useful when used with accompanying DRM/vGPU driver 
> > > in
> > >   guest domain which was designed to only work with contiguous 
> > > buffers,
> > >   e.g. DRM driver based on GEM CMA helpers: such drivers can only 
> > > import
> > >   contiguous PRIME buffers, thus requiring frontend driver to provide
> > >   such. In order to implement this mode of operation para-virtualized
> > >   frontend driver can be configured to use GEM CMA helpers.
> > > 
> > > 1.2. Front driver doesn't use GEM CMA
> > >   If accompanying drivers can cope with non-contiguous memory then, to
> > >   lower pressure on CMA subsystem of the kernel, driver can allocate
> > >   buffers from system memory.
> > > 
> > > Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
> > > may require IOMMU support on the platform, so accompanying DRM/vGPU
> > > hardware can still reach display buffer memory while importing PRIME
> > > buffers from the frontend driver.
> > > 
> > > 2. Buffers allocated by the backend
> > > 
> > > This mode of operation is run-time configured via guest domain 
> > > configuration
> > > through XenStore entries.
> > > 
> > > For systems which do not provide IOMMU support, but having specific
> > > requirements for display buffers it is possible to allocate such buffers
> > > at backend side and share those with the frontend.
> > > For example, if host domain is 1:1 mapped and has DRM/GPU hardware 
> > > expecting
> > > physically contiguous memory, this allows implementing zero-copying
> > > use-cases.
> > > 
> > > Note! Configuration options 1.1 (contiguous display buffers) and 2 
> > > (backend
> > > allocated buffers) are not supported at the same time.
> > > 
> > > Signed-off-by: Oleksandr Andrushchenko 
> > Some suggestions below for some larger cleanup work.
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/xen/Kconfig |  13 +
> > >   drivers/gpu/drm/xen/Makefile|   6 +
> > >   drivers/gpu/drm/xen/xen_drm_front.h |  74 ++
> > >   drivers/gpu/drm/xen/xen_drm_front_drv.c |  80 ++-
> > >   drivers/gpu/drm/xen/xen_drm_front_drv.h |   1 +
> > >   drivers/gpu/drm/xen/xen_drm_front_gem.c | 360 
> > > 
> > >   drivers/gpu/drm/xen/xen_drm_front_gem.h |  46 
> > >   drivers/gpu/drm/xen/xen_drm_front_gem_cma.c |  93 +++
> > >   8 files changed, 667 insertions(+), 6 deletions(-)
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.c
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.h
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c
> > > 
> > > diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
> > > index 4cca160782ab..4f4abc91f3b6 100644
> > > --- a/drivers/gpu/drm/xen/Kconfig
> > > +++ b/drivers/gpu/drm/xen/Kconfig
> > > @@ -15,3 +15,16 @@ config DRM_XEN_FRONTEND
> > >   help
> > > Choose this option if you want to enable a para-virtualized
> > > frontend DRM/KMS driver for Xen guest OSes.
> > > +
> > > +config DRM_XEN_FRONTEND_CMA
> > > + bool "Use DRM CMA to allocate dumb buffers"
> > > + depends on DRM_XEN_FRONTEND
> > > + select DRM_KMS_CMA_HELPER
> > > + select DRM_GEM_CMA_HELPER
> > > + help
> > > +   Use DRM CMA helpers to allocate display buffers.
> > > +   This is useful for the use-cases when guest driver needs to
> > > +   share or export buffers to other drivers which only expect
> > > +   contiguous buffers.
> > > +   Note: in this mode driver cannot use buffers allocated
> > > +   by the backend.
> > > diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
> > > index 4fcb0da1a9c5..12376ec78fbc 100644
> > > --- a/drivers/gpu/drm/xen/Makefile
> > > +++ b/drivers/gpu/drm/xen/Makefile
> > > @@ -8,4 +8,10 @@ drm_xen_front-objs

[Xen-devel] [qemu-upstream-unstable test] 120241: tolerable FAIL - PUSHED

[osstest service owner]

flight 120241 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120241/

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuua19f3519ed720f103b56dc2969993a60e76ee3f1
baseline version:
 qemuu2b033e396f4fa0981bae1213cdacd15775655a97

Last test of basis   117814  2018-01-11 08:55:06 Z   53 days
Testing same since   120163  2018-03-02 16:54:20 Z3 days2 attempts


People who touched revisions under test:
  Alex Bennée 
  Alex Williamson 
  Anthony PERARD 
  Aurelien Jarno 
  Christian Borntraeger 
  Claudio Imbrenda 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel Henrique Barboza 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  David Gibson 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Gerd Hoffmann 
  Greg Kurz 
  Igor Mammedov 
  Jay Zhou 
  Jose Ricardo Ziviani 
  Juan Quintela 
  Kevin Wolf 
  Laurent Vivier 
  Laurent Vivier 
  linzhecheng 
  linzhecheng 
  Marcel Apfelbaum 
  Markus Armbruster 
  Michael Roth 
  Michael S. Tsirkin 
  Murilo Opsfelder Araujo 
  Paolo Bonzini 
  Peter Lieven 
  Peter Maydell 
  Peter Xu 
  Philipp

Re: [Xen-devel] [PATCH 7/9] drm/xen-front: Implement KMS/connector handling

[Daniel Vetter]

On Mon, Mar 05, 2018 at 02:59:23PM +0200, Oleksandr Andrushchenko wrote:
> On 03/05/2018 11:23 AM, Daniel Vetter wrote:
> > On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko 
> > > 
> > > Implement kernel modesetiing/connector handling using
> > > DRM simple KMS helper pipeline:
> > > 
> > > - implement KMS part of the driver with the help of DRM
> > >simple pipepline helper which is possible due to the fact
> > >that the para-virtualized driver only supports a single
> > >(primary) plane:
> > >- initialize connectors according to XenStore configuration
> > >- handle frame done events from the backend
> > >- generate vblank events
> > >- create and destroy frame buffers and propagate those
> > >  to the backend
> > >- propagate set/reset mode configuration to the backend on display
> > >  enable/disable callbacks
> > >- send page flip request to the backend and implement logic for
> > >  reporting backend IO errors on prepare fb callback
> > > 
> > > - implement virtual connector handling:
> > >- support only pixel formats suitable for single plane modes
> > >- make sure the connector is always connected
> > >- support a single video mode as per para-virtualized driver
> > >  configuration
> > > 
> > > Signed-off-by: Oleksandr Andrushchenko 
> > I think once you've removed the midlayer in the previous patch it would
> > makes sense to merge the 2 patches into 1.
> ok, will squash the two
> > 
> > Bunch more comments below.
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/xen/Makefile |   2 +
> > >   drivers/gpu/drm/xen/xen_drm_front_conn.c | 125 +
> > >   drivers/gpu/drm/xen/xen_drm_front_conn.h |  35 
> > >   drivers/gpu/drm/xen/xen_drm_front_drv.c  |  15 ++
> > >   drivers/gpu/drm/xen/xen_drm_front_drv.h  |  12 ++
> > >   drivers/gpu/drm/xen/xen_drm_front_kms.c  | 299 
> > > +++
> > >   drivers/gpu/drm/xen/xen_drm_front_kms.h  |  30 
> > >   7 files changed, 518 insertions(+)
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.c
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.h
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.c
> > >   create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.h
> > > 
> > > diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
> > > index d3068202590f..4fcb0da1a9c5 100644
> > > --- a/drivers/gpu/drm/xen/Makefile
> > > +++ b/drivers/gpu/drm/xen/Makefile
> > > @@ -2,6 +2,8 @@
> > >   drm_xen_front-objs := xen_drm_front.o \
> > > xen_drm_front_drv.o \
> > > +   xen_drm_front_kms.o \
> > > +   xen_drm_front_conn.o \
> > > xen_drm_front_evtchnl.o \
> > > xen_drm_front_shbuf.o \
> > > xen_drm_front_cfg.o
> > > diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c 
> > > b/drivers/gpu/drm/xen/xen_drm_front_conn.c
> > > new file mode 100644
> > > index ..d9986a2e1a3b
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/xen/xen_drm_front_conn.c
> > > @@ -0,0 +1,125 @@
> > > +/*
> > > + *  Xen para-virtual DRM device
> > > + *
> > > + *   This program is free software; you can redistribute it and/or modify
> > > + *   it under the terms of the GNU General Public License as published by
> > > + *   the Free Software Foundation; either version 2 of the License, or
> > > + *   (at your option) any later version.
> > > + *
> > > + *   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.
> > > + *
> > > + * Copyright (C) 2016-2018 EPAM Systems Inc.
> > > + *
> > > + * Author: Oleksandr Andrushchenko 
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +
> > > +#include "xen_drm_front_conn.h"
> > > +#include "xen_drm_front_drv.h"
> > > +
> > > +static struct xen_drm_front_drm_pipeline *
> > > +to_xen_drm_pipeline(struct drm_connector *connector)
> > > +{
> > > + return container_of(connector, struct xen_drm_front_drm_pipeline, conn);
> > > +}
> > > +
> > > +static const uint32_t plane_formats[] = {
> > > + DRM_FORMAT_RGB565,
> > > + DRM_FORMAT_RGB888,
> > > + DRM_FORMAT_XRGB,
> > > + DRM_FORMAT_ARGB,
> > > + DRM_FORMAT_XRGB,
> > > + DRM_FORMAT_ARGB,
> > > + DRM_FORMAT_XRGB1555,
> > > + DRM_FORMAT_ARGB1555,
> > > +};
> > > +
> > > +const uint32_t *xen_drm_front_conn_get_formats(int *format_count)
> > > +{
> > > + *format_count = ARRAY_SIZE(plane_formats);
> > > + return plane_formats;
> > > +}
> > > +
> > > +static enum drm_connector_status connector_detect(
> > > + struct drm_connector *connector, bool force)
> > > +{
> > > + if (drm_dev_is_unplugg

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

[Juergen Gross]

On 05/03/18 13:35, Andrew Cooper wrote:
> On 05/03/18 12:06, Juergen Gross wrote:
>> On 05/03/18 12:50, Andrew Cooper wrote:
>>> On 05/03/18 11:31, Jan Beulich wrote:
>>> On 05.03.18 at 10:50,  wrote:
> Signed-off-by: Wei Liu 
 No description at all? I'd at least expect mention of how much of a
 performance win this is (for whichever hardware you happen to
 know that).

> @@ -120,11 +121,24 @@ unsigned int flush_area_local(const void *va, 
> unsigned int flags)
>  else
>  {
>  u32 t = pre_flush();
> -unsigned long cr4 = read_cr4();
>  
> -write_cr4(cr4 & ~X86_CR4_PGE);
> -barrier();
> -write_cr4(cr4);
> +if ( !cpu_has_invpcid )
> +{
> +unsigned long cr4 = read_cr4();
> +
> +write_cr4(cr4 & ~X86_CR4_PGE);
> +barrier();
> +write_cr4(cr4);
> +}
> +else
> +{
> +/*
> + * Using invpcid to flush all mappings works
> + * regardless of whether PCID is enabled or not.
> + * It is faster than read-modify-write CR4.
> + */
>>> Its a cr4 double write, rather than RMW.  We read from a cached value
>>> anyway, not from hardware.
>>>
> +invpcid_flush_all();
> +}
 The reference to PCID in the comment isn't really meaningful imo.
 PCID and INVPCID are independent features anyway. Also please
 don't create artificially short comment lines.

 Generally I also think such if() conditions would better be inverted:
 There's no reason to make the legacy form look as if it was
 preferred.

 And then - what about the use in write_cr3() and the two uses that
 remain after my XPTI follow-up series (which sadly looks to be stuck
 for whatever reason), or (without that series) the write_cr3
 assembler macro?
>>> I don't think it is safe to use invpcid when we're also switching cr3. 
>>> The new cr3 may have global pages with different translations, as they
>>> are guest controlled.
>> Can you elaborate a little bit more?
>>
>> How can a guest control any hypervisor mappings? As long as the new cr3
>> is being loaded before the TLB is flushed via INVPCID I can't see how
>> a problem should occur.
>>
>> In fact my series does exactly what Jan is asking above: it is replacing
>> the remaining cr4 based TLB flushing by INVPCID if possible. So in case
>> there is a flaw in my design please tell me.
> 
> At the moment, we have guest and hypervisor controlled global mappings.
> 
> The current switch is:
> cr4 &= ~PGE;
> cr3 = new_cr3;
> cr4 |= PGE;
> 
> which means that all global mappings are flushed by the first action,
> and no new global mappings can come into existence.  We then switch to
> the new cr3 (again with global fully disabled), then allow global
> mappings to come back into existence.
> 
> With the invpcid route, we switch via:
> 
> cr3 = new_cr3;
> invpcid all+global;
> 
> This has a race window where global mappings are active, and could
> mismatch what is in cr3.  This yields #MC on at least some hardware, and
> is specified to have undefined behaviour. 

Okay, so I will modify my patch series to use INVPCID only when global
mappings are disabled. With PCID available I'll use it for the non-XPTI
case, too. This will enable us to disable global mappings completely, so
INVPCID can always be used for flushing the TLB.


Juergen

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

Re: [Xen-devel] [PATCH v2 1/6] x86/xpti: avoid copying L4 page table contents when possible

[Juergen Gross]

On 05/03/18 17:43, Jan Beulich wrote:
 On 02.03.18 at 09:13,  wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -509,6 +509,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>  
>>  void write_ptbase(struct vcpu *v)
>>  {
>> +get_cpu_info()->root_pgt_changed = this_cpu(root_pgt) && is_pv_vcpu(v) 
>> &&
>> +   !is_pv_32bit_vcpu(v);
> 
> Why is_pv_vcpu() when you already check is_pv_32bit_vcpu()?

I check !is_pv_32bit_vcpu() to catch 64-bit pv-domains only.

> 
>> @@ -3704,18 +3706,22 @@ long do_mmu_update(
>>  break;
>>  rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
>>cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
>> -/*
>> - * No need to sync if all uses of the page can be 
>> accounted
>> - * to the page lock we hold, its pinned status, and 
>> uses on
>> - * this (v)CPU.
>> - */
>> -if ( !rc && !cpu_has_no_xpti &&
>> - ((page->u.inuse.type_info & PGT_count_mask) >
>> -  (1 + !!(page->u.inuse.type_info & PGT_pinned) +
>> -   (pagetable_get_pfn(curr->arch.guest_table) == 
>> mfn) 
>> +
>> -   (pagetable_get_pfn(curr->arch.guest_table_user) 
>> ==
>> -mfn))) )
>> -sync_guest = true;
>> +if ( !rc && !cpu_has_no_xpti )
>> +{
>> +get_cpu_info()->root_pgt_changed = true;
> 
> Why would you set this when a foreign domain's L4 got updated?

Right. I should set it only when modifying the currently active L4.

> And don't you need to disallow updating L4s of running guests now
> (which is a bad idea anyway)?

Yes, I should do that.

> 
>> --- a/xen/arch/x86/smp.c
>> +++ b/xen/arch/x86/smp.c
>> @@ -207,6 +207,8 @@ void invalidate_interrupt(struct cpu_user_regs *regs)
>>  unsigned int flags = flush_flags;
>>  ack_APIC_irq();
>>  perfc_incr(ipis);
>> +if ( flags & FLUSH_ROOT_PGTBL )
>> +get_cpu_info()->root_pgt_changed = true;
> 
> While for the caller in do_mmu_update() you don't need it, for
> full correctness you also want to do this in flush_area_mask()
> for the sender, if it's part of the CPU mask.

Right.


Juergen

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

Re: [Xen-devel] [PATCH v2 2/6] x86/xpti: don't flush TLB twice when switching to 64-bit pv context

[Juergen Gross]

On 05/03/18 17:49, Jan Beulich wrote:
 On 02.03.18 at 09:13,  wrote:
>> @@ -509,9 +510,16 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>>  
>>  void write_ptbase(struct vcpu *v)
>>  {
>> -get_cpu_info()->root_pgt_changed = this_cpu(root_pgt) && is_pv_vcpu(v) 
>> &&
>> -   !is_pv_32bit_vcpu(v);
>> -write_cr3(v->arch.cr3);
>> +if ( this_cpu(root_pgt) && is_pv_vcpu(v) && !is_pv_32bit_vcpu(v) )
>> +{
>> +get_cpu_info()->root_pgt_changed = true;
>> +asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
>> +}
>> +else
>> +{
>> +get_cpu_info()->root_pgt_changed = false;
> 
> Is this write really necessary?

Probably not. I'll drop it.


Juergen


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

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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 xen  ad95c2992679b9c2dae7c8bd30439c035f2493de
baseline version:
 xen  88fbabc49158b0b858248fa124ef590c5df7782f

Last test of basis   12  2018-02-24 21:12:43 Z9 days
Failing since120063  2018-02-27 13:55:23 Z6 days4 attempts
Testi

Re: [Xen-devel] [RFC QEMU PATCH v4 00/10] Implement vNVDIMM for Xen HVM guest

[Haozhong Zhang]

On 03/02/18 12:03 +, Anthony PERARD wrote:
> On Wed, Feb 28, 2018 at 05:36:59PM +0800, Haozhong Zhang wrote:
> > On 02/27/18 17:22 +, Anthony PERARD wrote:
> > > On Thu, Dec 07, 2017 at 06:18:02PM +0800, Haozhong Zhang wrote:
> > > > This is the QEMU part patches that works with the associated Xen
> > > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on
> > > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate
> > > > guest address space for vNVDIMM devices.
> > > 
> > > I've got other question, and maybe possible improvements.
> > > 
> > > When QEMU build the ACPI tables, it also initialize some MemoryRegion,
> > > which use more guest memory. Do you know if those regions are used with
> > > your patch series on Xen?
> > 
> > Yes, that's why dm_acpi_size is introduced.
> > 
> > > Otherwise, we could try to avoid their
> > > creation with this:
> > > In xenfv_machine_options()
> > > m->rom_file_has_mr = false;
> > > (setting this in xen_hvm_init() would probably be better, but I havn't
> > > try)
> > 
> > If my memory is correct, simply setting rom_file_has_mr to false does
> > not work (though I cannot remind the exact reason). I'll have a look
> > as the code to refresh my memory.
> 
> I've played a bit with this idea, but without a proper NVDIMM available
> for the guest, so I don't know if it's going to work properly without
> the mr.
> 
> To make it work, I had to disable some code in acpi_build_update() that
> make use of the MemoryRegions, as well as an assert in acpi_setup().
> After those small hacks, I could boot the guest, and I've check that the
> expected ACPI tables where there, and they looked correct to my eyes.
> And least `ndctl list` works and showed the nvdimm (that I have
> configured on QEMU's cmdline).
> 
> But I may not have been far enough with my tests, and maybe something
> later relies on the MRs, especially the _DSM method that I don't know if
> it was working properly.
> 
> Anyway, that why I proposed the idea, and if we can avoid more
> uncertainty about how much guest memory QEMU is going to use, that would
> be good.
> 

Yes, I also tested some non-trivial _DSM methods and it looks rom
files without memory regions can work with Xen after some
modifications. I'll apply this idea in the next version if no other
issues are found.

Thanks,
Haozhong

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

[Xen-devel] [linux-3.18 test] 120235: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
120132

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 120132
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 120132
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 120132
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 120132
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 120132
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 120132
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 120132
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux7c017f897e601aced95b71521bb0eb58af9002d5
baseline version:
 linux43a69271f55a952895915b69f6c50c90c4abdbcd

Last test of basis   120132  2018-03-01 20:10:32 Z4 days
Testing same since   120235  2018-03-04 13:53:20 Z1 days1 attempts


People who touched revisions under test:
  Al Viro 
  Alex Deucher 
  Alexander Kochetkov 
  Aliaksei Karaliou 
  Anna-Maria Gleixner 
  Benedict Wong 
  Boris Brezillon 
  Boris Ostrovsky 
  Brendan McGrath 
  Cathy Avery 
  Christophe JAILLET 
  Darrick J. Wong 
  David S. Miller 
  E

[Xen-devel] [qemu-mainline test] 120233: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd broken
 test-amd64-i386-qemuu-rhel6hvm-amd  4 host-install(4)  broken REGR. vs. 120095

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

version targeted for testing:
 qemuu136c67e07869227b21b3f627316e03679ce7b738
baseline version:
 qemuu6697439794f72b3501ee16bb95d16854f9981421

Last test of basis   120095  2018-02-28 13:46:33 Z5 days
Failing since120146  2018-03-02 10:10:57 Z3 days2 attempts
Testing same since   120233  2018-03-04 13:40:19 Z1 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Alistair Francis 
  Alistair Francis 
  Bastian Koppelmann 
  Christian Borntraeger 
  Collin L. Walling 
  Corey Minyard 
  Cornelia Huck 
  David Brenken 
  David Hildenbrand 
  Dr. David Alan Gilbert 
  Eric Blake 
  Fam Zheng 
  Florian Artmeier 
  Francisco Iglesias 
  Georg Hofstetter 
  Gonglei 
  Greg Kurz 
  Halil Pasic 
  Jan Kiszka 
  Janosch Frank 
  Ja

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f0b51c80fd347ccf2a469d2b8bb2a902fa23eeb7
baseline version:
 xen  f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1

Last test of basis   120268  2018-03-05 19:14:39 Z0 days
Testing same since   120271  2018-03-05 22:01:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Stefano Stabellini 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f75b1a5247..f0b51c80fd  f0b51c80fd347ccf2a469d2b8bb2a902fa23eeb7 -> smoke

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

[Xen-devel] [xen-4.6-testing test] 120238: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119227
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
119227

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 119187
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119227
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119227
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119227
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119227
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119227
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119227
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119227
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119227
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119227
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   76 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail 

Re: [Xen-devel] [PATCH] xl/libxl: add pvcalls support

[Stefano Stabellini]

ping?

On Tue, 27 Feb 2018, Stefano Stabellini wrote:
> Add pvcalls support to libxl and xl. Create the appropriate pvcalls
> entries in xenstore.
> 
> Signed-off-by: Stefano Stabellini 
> 
> diff --git a/docs/misc/xenstore-paths.markdown 
> b/docs/misc/xenstore-paths.markdown
> index 7be2592..77d1a36 100644
> --- a/docs/misc/xenstore-paths.markdown
> +++ b/docs/misc/xenstore-paths.markdown
> @@ -299,6 +299,11 @@ A virtual scsi device frontend. Described by
>  A virtual usb device frontend. Described by
>  [xen/include/public/io/usbif.h][USBIF]
>  
> + ~/device/pvcalls/$DEVID/* []
> +
> +Paravirtualized POSIX function calls frontend. Described by
> +[docs/misc/pvcalls.markdown][PVCALLS]
> +
>   ~/console/* []
>  
>  The primary PV console device. Described in [console.txt](console.txt)
> @@ -377,6 +382,10 @@ A PV SCSI backend.
>  
>  A PV USB backend. Described by
>  [xen/include/public/io/usbif.h][USBIF]
> + 
> + ~/backend/pvcalls/$DOMID/$DEVID/* []
> +
> +A PVCalls backend. Described in [docs/misc/pvcalls.markdown][PVCALLS].
>  
>   ~/backend/console/$DOMID/$DEVID/* []
>  
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 917ceb0..035e66e 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -140,7 +140,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o 
> libxl_dm.o libxl_pci.o \
>   libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
>   libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
>   libxl_9pfs.o libxl_domain.o libxl_vdispl.o \
> -$(LIBXL_OBJS-y)
> +libxl_pvcalls.o $(LIBXL_OBJS-y)
>  LIBXL_OBJS += libxl_genid.o
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
>  
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index eca0ea2..76574d2 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -2006,6 +2006,16 @@ int libxl_device_p9_destroy(libxl_ctx *ctx, uint32_t 
> domid,
>  const libxl_asyncop_how *ao_how)
>  LIBXL_EXTERNAL_CALLERS_ONLY;
>  
> +/* pvcalls */
> +int libxl_device_pvcalls_remove(libxl_ctx *ctx, uint32_t domid,
> +libxl_device_pvcalls *pvcalls,
> +const libxl_asyncop_how *ao_how)
> +LIBXL_EXTERNAL_CALLERS_ONLY;
> +int libxl_device_pvcalls_destroy(libxl_ctx *ctx, uint32_t domid,
> + libxl_device_pvcalls *pvcalls,
> + const libxl_asyncop_how *ao_how)
> + LIBXL_EXTERNAL_CALLERS_ONLY;
> +
>  /* PCI Passthrough */
>  int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid,
>   libxl_device_pci *pcidev,
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index c498135..bbdeee5 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -1374,6 +1374,9 @@ static void domcreate_launch_dm(libxl__egc *egc, 
> libxl__multidev *multidev,
>  for (i = 0; i < d_config->num_p9s; i++)
>  libxl__device_add(gc, domid, &libxl__p9_devtype, &d_config->p9s[i]);
>  
> +for (i = 0; i < d_config->num_pvcallss; i++)
> +libxl__device_add(gc, domid, &libxl__pvcalls_devtype, 
> &d_config->pvcallss[i]);
> +
>  switch (d_config->c_info.type) {
>  case LIBXL_DOMAIN_TYPE_HVM:
>  {
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 506687f..e9edfac 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -3648,6 +3648,7 @@ extern const struct libxl_device_type 
> libxl__usbdev_devtype;
>  extern const struct libxl_device_type libxl__pcidev_devtype;
>  extern const struct libxl_device_type libxl__vdispl_devtype;
>  extern const struct libxl_device_type libxl__p9_devtype;
> +extern const struct libxl_device_type libxl__pvcalls_devtype;
>  
>  extern const struct libxl_device_type *device_type_tbl[];
>  
> diff --git a/tools/libxl/libxl_pvcalls.c b/tools/libxl/libxl_pvcalls.c
> new file mode 100644
> index 000..a285343
> --- /dev/null
> +++ b/tools/libxl/libxl_pvcalls.c
> @@ -0,0 +1,37 @@
> +/*
> + * Copyright (C) 2018  Aporeto
> + * Author Stefano Stabellini 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * 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 Lesser General Public License for more details.
> + */
> +
> +#include "libxl_osdeps.h"
> +
> +#include "libxl_internal.h"
> +
> +static int 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1
baseline version:
 xen  18ee3250b5caad86f934207702a195f9688b59df

Last test of basis   120263  2018-03-05 16:01:10 Z0 days
Testing same since   120268  2018-03-05 19:14:39 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   18ee3250b5..f75b1a5247  f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1 -> smoke

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

[Xen-devel] [xen-4.7-testing test] 120232: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-pair broken
 test-amd64-i386-libvirt-pair broken
 test-amd64-i386-pair4 host-install/src_host(4) broken REGR. vs. 119780
 test-amd64-i386-libvirt-pair 5 host-install/dst_host(5) broken REGR. vs. 119780
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119780

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 119780
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 119780
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 119780
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119780
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 119780
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 119780
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 119780
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 119780
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 119780
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 119780
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 119780
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 119780
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 119780
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 w

Re: [Xen-devel] [PATCH LP-BUILD-TOOLS] Allow patching files compiled multiple times

[Konrad Rzeszutek Wilk]

On Mon, Mar 05, 2018 at 10:32:51AM +, Ross Lagerwall wrote:
> On 02/23/2018 05:08 PM, Ross Lagerwall wrote:
> > gas prior to binutils commit fbdf9406b0 (appears in 2.27) outputs symbol
> > table entries resulting from .file in reverse order. If we get two
> > consecutive file symbols, prefer the first one if that names an object
> > file or has a directory component (to cover multiply compiled files).
> > 
> > This is the same workaround that was applied in Xen commit d37d63d4b548
> > ("symbols: prefix static symbols with their source file names") for
> > Xen's internal symbol table.
> > 
> > This fixes building a livepatch for XSA-243.
> > ---
> >   lookup.c | 18 ++
> >   1 file changed, 18 insertions(+)
> > 
> > diff --git a/lookup.c b/lookup.c
> > index 39125c6..645b91a 100644
> > --- a/lookup.c
> > +++ b/lookup.c
> > @@ -149,16 +149,34 @@ int lookup_local_symbol(struct lookup_table *table, 
> > char *name, char *hint,
> > struct symbol *sym, *match = NULL;
> > int i;
> > char *curfile = NULL;
> > +   enum { other, multi_source } last_type = other;
> > memset(result, 0, sizeof(*result));
> > for_each_symbol(i, sym, table) {
> > if (sym->type == STT_FILE) {
> > +   const char *ext = strrchr(sym->name, '.');
> > +   int multi = strchr(sym->name, '/') ||
> > +   (ext && ext[1] == 'o');
> > +
> > +   /*
> > +* gas prior to binutils commit fbdf9406b0 (appears in
> > +* 2.27) outputs symbol table entries resulting from
> > +* .file in reverse order. If we get two consecutive
> > +* file symbols, prefer the first one if that names an
> > +* object file or has a directory component (to cover
> > +* multiply compiled files).
> > +*/
> > +   if (last_type == multi_source)
> > +   continue;
> > +
> > if (!strcmp(sym->name, hint)) {
> > curfile = sym->name;
> > +   last_type = multi ? multi_source : other;
> > continue; /* begin hint file symbols */

Perhaps add some logging as well?
> > } else if (curfile)
> > curfile = NULL; /* end hint file symbols */
> > }
> > +   last_type = other;
> > if (!curfile)
> > continue;
> > if (sym->bind == STB_LOCAL && !strcmp(sym->name, name)) {
> > 
> 
> Ping, Konrad?

This looks familiar, but how come it has no SoB?

> 
> -- 
> Ross Lagerwall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
118324
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 118324
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 118324
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 118324
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 118324
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 118324
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 118324
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 118324
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 118324

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl 

[Xen-devel] Merging 4.10.0-shim-comet-3 tag into staging-4.10

[Wei Liu]

Hi all

I merged 4.10.0-shim-comet-3 tag into staging-4.10, went through all
commits since then and cherry-picked relevant patches from master to
staging-4.10.

The end result is:

  
https://xenbits.xen.org/gitweb/?p=people/liuw/xen.git;a=shortlog;h=refs/heads/merge-comet-staging-4.10-v1

There is also a merge-comet-staging-4.10-v1-base tag.

The merge had trivial conflicts and I fixed it.

There are some notable things in the subsequent patches.

1. Revert "x86/guest: use the vcpu_info area from shared_info"

The bug fix is already in 4.10 branch so this workaround for comet is
not needed anymore.

2. xen/shim: stash RSDP address for ACPI driver

This isn't strictly necessary for 4.10 because the commiet that changes
the placement of RSDP is not in 4.10 libxl.

3. firmware/shim: update Makefile

This is a new patch to ease further cherry-picking for later commits.

Please check if the shape and form of this branch is OK. And please
indicate if anything is missing.

Building that branch seems to produce the expected binaries. I will do
some smoke tests tomorrow to make sure I haven't screwed things up.

Wei.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  18ee3250b5caad86f934207702a195f9688b59df
baseline version:
 xen  7bf61602f295676c8b0ff61e4c584fc2bd57e4cf

Last test of basis   120177  2018-03-03 00:03:39 Z2 days
Testing same since   120263  2018-03-05 16:01:10 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   7bf61602f2..18ee3250b5  18ee3250b5caad86f934207702a195f9688b59df -> smoke

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

Re: [Xen-devel] [PATCH v2 30/30] xen: use the BYTE-based definitions

[Anthony PERARD]

On Mon, Mar 05, 2018 at 08:27:32AM -0300, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
> 
> Patch generated using:
> 
>   $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
> 
> and modified manually.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> Reviewed-by: Alan Robinson 
> ---
>  hw/block/xen_disk.c|  4 ++--
>  hw/xenpv/xen_domainbuild.c | 10 +-
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 22/30] hw/display: use the BYTE-based definitions

[Anthony PERARD]

On Mon, Mar 05, 2018 at 08:27:24AM -0300, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
> 
> Patch generated using:
> 
>   $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
> 
> and modified manually.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> Reviewed-by: Gerd Hoffmann 
> ---
>  hw/display/xenfb.c  |  2 +-
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index f5afcc0358..1ae660519a 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -889,7 +889,7 @@ static int fb_initialise(struct XenDevice *xendev)
>   return rc;
>  
>  fb_page = fb->c.page;
> -rc = xenfb_configure_fb(fb, videoram * 1024 * 1024U,
> +rc = xenfb_configure_fb(fb, videoram * M_BYTE,
>   fb_page->width, fb_page->height, fb_page->depth,
>   fb_page->mem_length, 0, fb_page->line_length);
>  if (rc != 0)

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 08/30] hw/i386: use the BYTE-based definitions

[Anthony PERARD]

On Mon, Mar 05, 2018 at 08:27:10AM -0300, Philippe Mathieu-Daudé wrote:
> It eases code review, unit is explicit.
> 
> Patch generated using:
> 
>   $ git grep -E '(1024|2048|4096|8192|(<<|>>).?(10|20|30))' hw/ include/hw/
> 
> and modified manually.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/i386/xen/xen-mapcache.c |  2 +-
> 
> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> index efa35dc6e0..5f48fde799 100644
> --- a/hw/i386/xen/xen-mapcache.c
> +++ b/hw/i386/xen/xen-mapcache.c
> @@ -47,7 +47,7 @@
>   * From empirical tests I observed that qemu use 75MB more than the
>   * max_mcache_size.
>   */
> -#define NON_MCACHE_MEMORY_SIZE (80 * 1024 * 1024)
> +#define NON_MCACHE_MEMORY_SIZE (80 * M_BYTE)
>  
>  typedef struct MapCacheEntry {
>  hwaddr paddr_index;

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 3/6] xen/sched: Improvements to the {alloc, free}_domdata() interfaces

[Andrew Cooper]

Ping Dornerworks.

Any comment (on this and the next patch), or are you happy for these
trivial changes to fall under general scheduler maintainership?

~Andrew

On 28/02/18 14:14, Andrew Cooper wrote:
> The main purpose of this change is for the subsequent cleanup it enables, but
> it stands on its own merits.
>
> In principle, these hooks are optional, but the SCHED_OP() default aliases a
> memory allocation failure, which causes arinc653 to play the dangerous game of
> passing its priv pointer back, and remembering not to actually free it.
>
> Redefine alloc_domdata to use ERR_PTR() for errors, NULL for nothing, and
> non-NULL for a real allocation, which allows the hook to become properly
> optional.  Redefine free_domdata to be idempotent.
>
> For arinc653, this means the dummy hooks can be dropped entirely.  For the
> other schedulers, this means returning ERR_PTR(-ENOMEM) instead of NULL for
> memory allocation failures, and modifying the free hooks to cope with a NULL
> pointer.  While making the alterations, drop some spurious casts to void *.
>
> Introduce and use proper wrappers for sched_{alloc,free}_domdata().  These are
> strictly better than SCHED_OP(), as the source code is visible to
> grep/cscope/tags, the generated code is better, and there can be proper
> per-hook defaults and checks.
>
> Callers of the alloc hooks are switched to using IS_ERR(), rather than
> checking for NULL.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: George Dunlap 
> CC: Dario Faggioli 
> CC: Meng Xu 
> CC: Josh Whitehead 
> CC: Robert VanVossen 
> ---
>  xen/common/sched_arinc653.c | 31 ---
>  xen/common/sched_credit.c   |  8 
>  xen/common/sched_credit2.c  | 24 +---
>  xen/common/sched_null.c | 22 +-
>  xen/common/sched_rt.c   | 21 +
>  xen/common/schedule.c   | 12 ++--
>  xen/include/xen/sched-if.h  | 27 ++-
>  7 files changed, 75 insertions(+), 70 deletions(-)
>
> diff --git a/xen/common/sched_arinc653.c b/xen/common/sched_arinc653.c
> index 982845b..17e765d 100644
> --- a/xen/common/sched_arinc653.c
> +++ b/xen/common/sched_arinc653.c
> @@ -455,34 +455,6 @@ a653sched_free_vdata(const struct scheduler *ops, void 
> *priv)
>  }
>  
>  /**
> - * This function allocates scheduler-specific data for a domain
> - *
> - * We do not actually make use of any per-domain data but the hypervisor
> - * expects a non-NULL return value
> - *
> - * @param ops   Pointer to this instance of the scheduler structure
> - *
> - * @return  Pointer to the allocated data
> - */
> -static void *
> -a653sched_alloc_domdata(const struct scheduler *ops, struct domain *dom)
> -{
> -/* return a non-NULL value to keep schedule.c happy */
> -return SCHED_PRIV(ops);
> -}
> -
> -/**
> - * This function frees scheduler-specific data for a domain
> - *
> - * @param ops   Pointer to this instance of the scheduler structure
> - */
> -static void
> -a653sched_free_domdata(const struct scheduler *ops, void *data)
> -{
> -/* nop */
> -}
> -
> -/**
>   * Xen scheduler callback function to sleep a VCPU
>   *
>   * @param ops   Pointer to this instance of the scheduler structure
> @@ -740,9 +712,6 @@ static const struct scheduler sched_arinc653_def = {
>  .free_vdata = a653sched_free_vdata,
>  .alloc_vdata= a653sched_alloc_vdata,
>  
> -.free_domdata   = a653sched_free_domdata,
> -.alloc_domdata  = a653sched_alloc_domdata,
> -
>  .init_domain= NULL,
>  .destroy_domain = NULL,
>  
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index f8212db..e2133df 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -1282,7 +1282,7 @@ csched_alloc_domdata(const struct scheduler *ops, 
> struct domain *dom)
>  
>  sdom = xzalloc(struct csched_dom);
>  if ( sdom == NULL )
> -return NULL;
> +return ERR_PTR(-ENOMEM);
>  
>  /* Initialize credit and weight */
>  INIT_LIST_HEAD(&sdom->active_vcpu);
> @@ -1290,7 +1290,7 @@ csched_alloc_domdata(const struct scheduler *ops, 
> struct domain *dom)
>  sdom->dom = dom;
>  sdom->weight = CSCHED_DEFAULT_WEIGHT;
>  
> -return (void *)sdom;
> +return sdom;
>  }
>  
>  static int
> @@ -1302,8 +1302,8 @@ csched_dom_init(const struct scheduler *ops, struct 
> domain *dom)
>  return 0;
>  
>  sdom = csched_alloc_domdata(ops, dom);
> -if ( sdom == NULL )
> -return -ENOMEM;
> +if ( IS_ERR(sdom) )
> +return PTR_ERR(sdom);
>  
>  dom->sched_priv = sdom;
>  
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index b094b3c..29a24d6 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -3012,7 +3012,7 @@ csched2_alloc_domdata(const struct scheduler *ops, 
> struct domain *dom)
>  
>  sdom = xzalloc(struct csched2_dom);
>  if ( sdom == NULL )
> -   

Re: [Xen-devel] [PATCH 00/57] New VGIC(-v2) implementation

[Andre Przywara]

Hi,

On 05/03/18 16:03, Andre Przywara wrote:
> tl;dr: Coarse changelog below, individual patches have changelogs as
> well.
> 
> This is an updated version of the new VGIC-v2 implementation.

For the brave amongst you who actually want to try it, there is a git
repo with these patches on top of current origin/staging:
http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/vgic-new/v1
git://linux-arm.org/xen-ap.git branch vgic-new/v1

Cheers,
Andre.

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

Re: [Xen-devel] [PATCH 01/57] tools: ARM: vGICv3: Avoid inserting optional DT properties

[Wei Liu]

On Mon, Mar 05, 2018 at 04:39:09PM +, Julien Grall wrote:
> (+ tools maintainers)
> 
> Hi Andre,
> 
> Please don't forget to CC the relevant maintainers.
> 
> On 05/03/18 16:03, Andre Przywara wrote:
> > When creating a GICv3 devicetree node, we currently insert the
> > redistributor-stride and #redistributor-regions properties, with fixed
> > values which are actually the architected ones. Since those properties are
> > optional, and in the case of the stride only needed to cover for broken
> > platforms, we don't need to describe them if they don't differ from the
> > default values. This will always be the case for our constructed
> > DomU memory map.
> > So we drop those properties altogether and provide a clean and architected
> > GICv3 DT node for DomUs.
> > 
> > Signed-off-by: Andre Przywara 
> 
> Reviewed-by: Julien Grall 
> 

Acked-by: Wei Liu 

Julien please commit this yourself.

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

Re: [Xen-devel] [PATCH 09/57] ARM: VGIC: Move domain_max_vcpus() to be VGIC specific

[Julien Grall]

Hi Andre,

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

domain_max_vcpus(), which is used by generic Xen code, returns the
maximum number of VCPUs for a domain, which on ARM is mostly limited by
the VGIC model emulated (a (v)GICv2 can only handle 8 CPUs).
Our current implementation lives in arch/arm/domain.c, but reaches into
VGIC internal data structures.
Move this function into vgic.c, to keep this VGIC internal.


While I understand the reason behind moving the code in vGIC, it feels a 
bit strange to have a domain function in vgic.c code.


How about renaming the function with a dummy helper in domain.h to 
accommodate common code? Maybe with a comment on top?


Cheers,



Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- dump previous approach, move function to VGIC specific file instead

  xen/arch/arm/domain.c | 14 --
  xen/arch/arm/vgic.c   | 14 ++
  2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a010443bfd..8546443bad 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -968,20 +968,6 @@ void vcpu_block_unless_event_pending(struct vcpu *v)
  vcpu_unblock(current);
  }
  
-unsigned int domain_max_vcpus(const struct domain *d)

-{
-/*
- * Since evtchn_init would call domain_max_vcpus for poll_mask
- * allocation when the vgic_ops haven't been initialised yet,
- * we return MAX_VIRT_CPUS if d->arch.vgic.handler is null.
- */
-if ( !d->arch.vgic.handler )
-return MAX_VIRT_CPUS;
-else
-return min_t(unsigned int, MAX_VIRT_CPUS,
- d->arch.vgic.handler->max_vcpus);
-}
-
  /*
   * Local variables:
   * mode: C
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 34269bcf27..c3fdcebbde 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -665,6 +665,20 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
  clear_bit(virq, d->arch.vgic.allocated_irqs);
  }
  
+unsigned int domain_max_vcpus(const struct domain *d)

+{
+/*
+ * Since evtchn_init would call domain_max_vcpus for poll_mask
+ * allocation when the vgic_ops haven't been initialised yet,
+ * we return MAX_VIRT_CPUS if d->arch.vgic.handler is null.
+ */
+if ( !d->arch.vgic.handler )
+return MAX_VIRT_CPUS;
+else
+return min_t(unsigned int, MAX_VIRT_CPUS,
+ d->arch.vgic.handler->max_vcpus);
+}
+
  /*
   * Local variables:
   * mode: C



--
Julien Grall

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

Re: [Xen-devel] [PATCH 07/57] ARM: VGIC: rename gic_inject() and gic_clear_lrs()

[Julien Grall]

Hi Andre,

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

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

Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,


---
Changelog RFC ... v1:
- new patch

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

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index d273863556..c0fe38fd37 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -247,7 +247,7 @@ static void gic_update_one_lr(struct vcpu *v, int i)
  }
  }
  
-void gic_clear_lrs(struct vcpu *v)

+void vgic_sync_from_lrs(struct vcpu *v)
  {
  int i = 0;
  unsigned long flags;
@@ -377,7 +377,7 @@ out:
  return rc;
  }
  
-void gic_inject(void)

+void vgic_sync_to_lrs(void)
  {
  ASSERT(!local_irq_is_enabled());
  
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c

index 1cba7e584d..7411bff7a7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,7 +2024,7 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
  if ( current->arch.hcr_el2 & HCR_VA )
  current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
  
-gic_clear_lrs(current);

+vgic_sync_from_lrs(current);
  }
  }
  
@@ -2234,7 +2234,7 @@ void leave_hypervisor_tail(void)

  {
  local_irq_disable();
  if (!softirq_pending(smp_processor_id())) {
-gic_inject();
+vgic_sync_to_lrs();
  
  /*

   * If the SErrors handle option is "DIVERSE", we have to prevent
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 497f195bc1..e2ae4254ed 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -237,7 +237,7 @@ extern int gic_route_irq_to_guest(struct domain *, unsigned 
int virq,
  int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
struct irq_desc *desc);
  
-extern void gic_inject(void);

+extern void vgic_sync_to_lrs(void);
  extern void gic_clear_pending_irqs(struct vcpu *v);
  extern int gic_events_need_delivery(void);
  
@@ -295,7 +295,7 @@ extern unsigned int gic_number_lines(void);

  /* IRQ translation function for the device tree */
  int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
unsigned int *out_hwirq, unsigned int *out_type);
-void gic_clear_lrs(struct vcpu *v);
+void vgic_sync_from_lrs(struct vcpu *v);
  
  struct gic_info {

  /* GIC version */



--
Julien Grall

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

Re: [Xen-devel] [PATCH 04/57] ARM: GICv3: simplify GICv3 redistributor stride handling

[Julien Grall]

Hi Andre,

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

Instead of hard coding the architected redistributor stride into the
code, lets use a clear #define to the two values for GICv3 and GICv4 and
clarify the algorithm to determine the needed stride value.

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

  xen/arch/arm/gic-v3.c | 18 ++
  xen/include/asm-arm/gic_v3_defs.h |  5 +
  2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b1f8a86409..be1787b39a 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -690,6 +690,15 @@ static int __init gicv3_populate_rdist(void)
  do {
  typer = readq_relaxed(ptr + GICR_TYPER);
  
+/* Set the architectural redist size if not overridden by DT. */

+if ( !gicv3.rdist_stride )
+{
+if ( typer & GICR_TYPER_VLPIS )


Is there anything in the spec promising you that *all* the 
redistributors will support vLPIs?


But I am not fully convinced of having this patch in Xen. I feel it 
makes the code more confusing to read. The current code shows that the 
next re-distributor start is based on the current TYPER values. So I 
think it would make sense to just rework the current code:


if ( gicv3.rdist_stride )
{
   ptr += ...
}
else
{
  if ( typer & GICR_TYPER_VLPIS )
ptr += GICV4_GICR_SIZE;
  else
ptr += GICV3_GICR_SIZE;
}


+gicv3.rdist_stride = GICV4_GICR_SIZE;
+else
+gicv3.rdist_stride = GICV3_GICR_SIZE;
+} > +
  if ( (typer >> 32) == aff )
  {
  this_cpu(rbase) = ptr;
@@ -732,14 +741,7 @@ static int __init gicv3_populate_rdist(void)
  if ( gicv3.rdist_regions[i].single_rdist )
  break;
  
-if ( gicv3.rdist_stride )

-ptr += gicv3.rdist_stride;
-else
-{
-ptr += SZ_64K * 2; /* Skip RD_base + SGI_base */
-if ( typer & GICR_TYPER_VLPIS )
-ptr += SZ_64K * 2; /* Skip VLPI_base + reserved page */
-}
+ptr += gicv3.rdist_stride;
  
  } while ( !(typer & GICR_TYPER_LAST) );

  }
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 65c9dc47cf..412e41afed 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -18,6 +18,8 @@
  #ifndef __ASM_ARM_GIC_V3_DEFS_H__
  #define __ASM_ARM_GIC_V3_DEFS_H__
  
+#include 

+
  /*
   * Additional registers defined in GIC v3.
   * Common GICD registers are defined in gic.h
@@ -68,6 +70,9 @@
  #define GICV3_GICD_IIDR_VAL  0x34c
  #define GICV3_GICR_IIDR_VAL  GICV3_GICD_IIDR_VAL
  
+#define GICV3_GICR_SIZE  (2 * SZ_64K)

+#define GICV4_GICR_SIZE  (4 * SZ_64K)


Do you mind adding a comment either linking to the spec (Section 8.10 
ARM IHI 0069D) or explain the 2/4?



+
  #define GICR_CTLR(0x)
  #define GICR_IIDR(0x0004)
  #define GICR_TYPER   (0x0008)



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] new config option vtsc_khz_tolerance to avoid TSC emulation

[Olaf Hering]

Am Mon, 05 Mar 2018 07:45:24 -0700
schrieb "Jan Beulich" :

> I'm only talking about additions you make, and I don't see a size
> difference between "vtsc_khz_tolerance" and "vtsc_tolerance_khz".

Oh, I misunderstood that sentence. I will change the name as suggested.

Olaf


pgpAL8vUoPoeQ.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [FIXUP] replace LOG_2 with ilog2

[Andre Przywara]

The macro formerly named LOG_2 has been recently renamed to ilog2,
so adjust the name in vgic-mmio.h.

Signed-off-by: Andre Przywara 
---
Hi,

I somehow rebased without actually trying to re-compile (since the rebase
itself went through smoothly). So I missed this subtle renaming in the tree.
Please apply this patch (or merge it into
"[PATCH 34/57] ARM: new VGIC: Add MMIO handling framework") to get actually
something that compiles.
Apologies for that mishap!

Cheers,
Andre

 xen/arch/arm/vgic/vgic-mmio.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio.h b/xen/arch/arm/vgic/vgic-mmio.h
index bbf0d181ae..5e6cff9eb2 100644
--- a/xen/arch/arm/vgic/vgic-mmio.h
+++ b/xen/arch/arm/vgic/vgic-mmio.h
@@ -49,7 +49,7 @@ extern struct mmio_handler_ops vgic_io_ops;
  * This assumes that  is a power of two.
  */
 #define VGIC_ADDR_TO_INTID(addr, bits)  (((addr) & VGIC_ADDR_IRQ_MASK(bits)) * 
\
- 8 >> LOG_2(bits))
+ 8 >> ilog2(bits))
 
 /*
  * Some VGIC registers store per-IRQ information, with a different number
-- 
2.14.1


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

Re: [Xen-devel] [PATCH v2 2/6] x86/xpti: don't flush TLB twice when switching to 64-bit pv context

[Jan Beulich]

>>> On 02.03.18 at 09:13,  wrote:
> @@ -509,9 +510,16 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>  
>  void write_ptbase(struct vcpu *v)
>  {
> -get_cpu_info()->root_pgt_changed = this_cpu(root_pgt) && is_pv_vcpu(v) &&
> -   !is_pv_32bit_vcpu(v);
> -write_cr3(v->arch.cr3);
> +if ( this_cpu(root_pgt) && is_pv_vcpu(v) && !is_pv_32bit_vcpu(v) )
> +{
> +get_cpu_info()->root_pgt_changed = true;
> +asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
> +}
> +else
> +{
> +get_cpu_info()->root_pgt_changed = false;

Is this write really necessary?

Jan


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

Re: [Xen-devel] [PATCH 03/57] ARM: GICv3: use hardware GICv3 redistributor values for Dom0

[Julien Grall]

Hi Andre,

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

The code to generate the DT node or MADT table for Dom0 reaches into the
domain's VGIC structure to learn the number of redistributor regions and


Mega NIT: Can you either use VGIC or vGIC within the same patch? :)


their base addresses.
Since those values are copied from the hardware, we can as well use
those hardware values directly when setting up the hardware domain.

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

Signed-off-by: Andre Przywara 


Reviewed-by: Julien Grall 

Cheers,


---
Changelog RFC ... v1:
- Use GIC hardware values consistently in this function.

  xen/arch/arm/gic-v3.c | 17 +++--
  1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 25c30bb9ea..b1f8a86409 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1162,13 +1162,11 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
  if ( res )
  return res;
  
-res = fdt_property_cell(fdt, "redistributor-stride",

-d->arch.vgic.rdist_stride);
+res = fdt_property_cell(fdt, "redistributor-stride", gicv3.rdist_stride);
  if ( res )
  return res;
  
-res = fdt_property_cell(fdt, "#redistributor-regions",

-d->arch.vgic.nr_regions);
+res = fdt_property_cell(fdt, "#redistributor-regions", gicv3.rdist_count);
  if ( res )
  return res;
  
@@ -1178,7 +1176,7 @@ static int gicv3_make_hwdom_dt_node(const struct domain *d,

   * CPU interface and virtual cpu interfaces accessesed as System registers
   * So cells are created only for Distributor and rdist regions
   */
-new_len = new_len * (d->arch.vgic.nr_regions + 1);
+new_len = new_len * (gicv3.rdist_count + 1);
  
  hw_reg = dt_get_property(gic, "reg", &len);

  if ( !hw_reg )
@@ -1406,13 +1404,13 @@ static int gicv3_make_hwdom_madt(const struct domain 
*d, u32 offset)
  
  /* Add Generic Redistributor */

  size = sizeof(struct acpi_madt_generic_redistributor);
-for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
+for ( i = 0; i < gicv3.rdist_count; i++ )
  {
  gicr = (struct acpi_madt_generic_redistributor *)(base_ptr + 
table_len);
  gicr->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
  gicr->header.length = size;
-gicr->base_address = d->arch.vgic.rdist_regions[i].base;
-gicr->length = d->arch.vgic.rdist_regions[i].size;
+gicr->base_address = gicv3.rdist_regions[i].base;
+gicr->length = gicv3.rdist_regions[i].size;
  table_len += size;
  }
  
@@ -1425,8 +1423,7 @@ static unsigned long gicv3_get_hwdom_extra_madt_size(const struct domain *d)

  {
  unsigned long size;
  
-size = sizeof(struct acpi_madt_generic_redistributor)

-   * d->arch.vgic.nr_regions;
+size = sizeof(struct acpi_madt_generic_redistributor) * gicv3.rdist_count;
  
  size += sizeof(struct acpi_madt_generic_translator)

  * vgic_v3_its_count(d);



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/6] x86/xpti: avoid copying L4 page table contents when possible

[Jan Beulich]

>>> On 02.03.18 at 09:13,  wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -509,6 +509,8 @@ void make_cr3(struct vcpu *v, mfn_t mfn)
>  
>  void write_ptbase(struct vcpu *v)
>  {
> +get_cpu_info()->root_pgt_changed = this_cpu(root_pgt) && is_pv_vcpu(v) &&
> +   !is_pv_32bit_vcpu(v);

Why is_pv_vcpu() when you already check is_pv_32bit_vcpu()?

> @@ -3704,18 +3706,22 @@ long do_mmu_update(
>  break;
>  rc = mod_l4_entry(va, l4e_from_intpte(req.val), mfn,
>cmd == MMU_PT_UPDATE_PRESERVE_AD, v);
> -/*
> - * No need to sync if all uses of the page can be 
> accounted
> - * to the page lock we hold, its pinned status, and uses 
> on
> - * this (v)CPU.
> - */
> -if ( !rc && !cpu_has_no_xpti &&
> - ((page->u.inuse.type_info & PGT_count_mask) >
> -  (1 + !!(page->u.inuse.type_info & PGT_pinned) +
> -   (pagetable_get_pfn(curr->arch.guest_table) == 
> mfn) 
> +
> -   (pagetable_get_pfn(curr->arch.guest_table_user) ==
> -mfn))) )
> -sync_guest = true;
> +if ( !rc && !cpu_has_no_xpti )
> +{
> +get_cpu_info()->root_pgt_changed = true;

Why would you set this when a foreign domain's L4 got updated?
And don't you need to disallow updating L4s of running guests now
(which is a bad idea anyway)?

> --- a/xen/arch/x86/smp.c
> +++ b/xen/arch/x86/smp.c
> @@ -207,6 +207,8 @@ void invalidate_interrupt(struct cpu_user_regs *regs)
>  unsigned int flags = flush_flags;
>  ack_APIC_irq();
>  perfc_incr(ipis);
> +if ( flags & FLUSH_ROOT_PGTBL )
> +get_cpu_info()->root_pgt_changed = true;

While for the caller in do_mmu_update() you don't need it, for
full correctness you also want to do this in flush_area_mask()
for the sender, if it's part of the CPU mask.

Jan


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

Re: [Xen-devel] [PATCH 02/57] ARM: vGICv3: clarify on GUEST_GICV3_RDIST_REGIONS symbol

[Julien Grall]

Hi Andre,

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

Normally there is only one GICv3 redistributor region, and we use
that for DomU guests using a GICv3.
Explain the background in a comment and why we need to keep the number
of hardware regions for Dom0.

Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,


---
Changelog RFC ... v1:
- Keep GUEST_GICV3_RDIST_REGIONS symbol around, just extend comments

  xen/arch/arm/vgic-v3.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 2ad8a6be62..d5b34a7d0f 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1632,6 +1632,16 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
  
  static inline unsigned int vgic_v3_rdist_count(struct domain *d)

  {
+/*
+ * Normally there is only one GICv3 redistributor region.
+ * The GICv3 DT binding provisions for multiple regions, since there are
+ * platforms out there which need those (multi-socket systems).
+ * For Dom0 we have to live with the MMIO layout the hardware provides,
+ * so we have to copy the multiple regions - as the first region may not
+ * provide enough space to hold all redistributors we need.
+ * However DomU get a constructed memory map, so we can go with
+ * the architected single redistributor region.
+ */
  return is_hardware_domain(d) ? vgic_v3_hw.nr_rdist_regions :
 GUEST_GICV3_RDIST_REGIONS;
  }
@@ -1692,7 +1702,7 @@ static int vgic_v3_domain_init(struct domain *d)
  {
  d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
  
-/* XXX: Only one Re-distributor region mapped for the guest */

+/* A single Re-distributor region is mapped for the guest. */
  BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
  
  d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;




--
Julien Grall

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

Re: [Xen-devel] [PATCH 01/57] tools: ARM: vGICv3: Avoid inserting optional DT properties

[Julien Grall]

(+ tools maintainers)

Hi Andre,

Please don't forget to CC the relevant maintainers.

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

When creating a GICv3 devicetree node, we currently insert the
redistributor-stride and #redistributor-regions properties, with fixed
values which are actually the architected ones. Since those properties are
optional, and in the case of the stride only needed to cover for broken
platforms, we don't need to describe them if they don't differ from the
default values. This will always be the case for our constructed
DomU memory map.
So we drop those properties altogether and provide a clean and architected
GICv3 DT node for DomUs.

Signed-off-by: Andre Przywara 


Reviewed-by: Julien Grall 

Cheers,


---
Changelog RFC ... v1:
- improve commit message

  tools/libxl/libxl_arm.c | 8 
  1 file changed, 8 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 86f59c0d80..906fd0dcdf 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -525,14 +525,6 @@ static int make_gicv3_node(libxl__gc *gc, void *fdt)
  res = fdt_property(fdt, "interrupt-controller", NULL, 0);
  if (res) return res;
  
-res = fdt_property_cell(fdt, "redistributor-stride",

-GUEST_GICV3_RDIST_STRIDE);
-if (res) return res;
-
-res = fdt_property_cell(fdt, "#redistributor-regions",
-GUEST_GICV3_RDIST_REGIONS);
-if (res) return res;
-
  res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
  2,
  gicd_base, gicd_size,



--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 0/6] xen/x86: various XPTI speedups

[Dario Faggioli]

On Fri, 2018-03-02 at 09:13 +0100, Juergen Gross wrote:
> The complete series has been verified to still mitigate against
> Meltdown attacks. A simple performance test (make -j 4 in the Xen
> hypervisor directory) showed significant improvements compared to the
> state without this series (so with Jan's and Wei's series applied),
> the percentage after the numbers is always related to XPTI off:
> 
>XPTI off Jan+Wei, XPTI on+this series, XPTI on
> real   1m21.169s1m52.149s (+38%)1m25.692s (+6%)
> user   2m47.652s2m50.054s (+1%) 2m46.428s (-1%)
> sys1m11.949s2m21.767s (+97%)1m23.053s (+15%)
> 
> A git branch of that series (+ Jan's and Wei's patches) is available:
> 
> https://github.com/jgross1/xen.git xpti
> 
I've run some more benchmarks, and here there are the results:

https://openbenchmarking.org/result/1803039-DARI-180303217
http://openbenchmarking.org/result/1803039-DARI-180303217&obr_nor=y&obr_hgv=Jan%2BWei%2C+XPTI+on

(I also include a textual recap at the bottom of this email.)

These numbers shows that Juergen's series is quite effective at
improving performance in pretty much all workloads that I've tested.

The only exception is schbench, but I don't think that's very relevant,
because of how the benchmark is configured in the PhoronixTestSuite (I
just recently discovered that).

The in-guest context-switching heavy workloads are the ones where this
series makes the most (positive) difference.

Note that on Stream and on Stress-ng:MemoryCopy, XPTI=on+this series
does even *better* than XPTI=off. This is most likely due to the fact
that Juergen, for now, takes advantage of PCID only for the XPTI=on
case. However, although it is indeed a bit of an unfair comparison, I
think it does prove the point that we want to have (something like)
this series.

Regards,
Dario

AIO-Stress 0.21
Test: Random Write
MB/s > Higher Is Better
XPTI off ... 1926.57 
|=
+this series, XPTI on .. 1931.44 
|=
Jan+Wei, XPTI on ... 1807.30 
|==

Stream 2013-01-17
Type: Copy
MB/s > Higher Is Better
XPTI off ... 15738.48 
|==
+this series, XPTI on .. 19011.66 
|
Jan+Wei, XPTI on ... 15381.94 
|===

Stream 2013-01-17
Type: Scale
MB/s > Higher Is Better
XPTI off ... 10849.14 
|=
+this series, XPTI on .. 12833.84 
|
Jan+Wei, XPTI on ... 10696.66 
|===

Stream 2013-01-17
Type: Triad
MB/s > Higher Is Better
XPTI off ... 12268.20 
|==
+this series, XPTI on .. 14085.56 
|
Jan+Wei, XPTI on ... 12120.56 
|

Stream 2013-01-17
Type: Add
MB/s > Higher Is Better
XPTI off ... 12323.60 
|=
+this series, XPTI on .. 15881.14 
|
Jan+Wei, XPTI on ... 12085.76 
|===

[Xen-devel] [PATCH 24/57] ARM: timer: Handle level triggered IRQs correctly

[Andre Przywara]

The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we have to sync the state of the interrupt condition at certain
points to catch when the line goes low and we can remove the vtimer vIRQ
from the vGIC (and the LR).
The VGIC in Xen so far only implemented edge triggered vIRQs, really, so
we need to add new functionality to re-sample the interrupt state.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- extend comments
- don't read CNTV_CVAL_EL0
- use symbolic names for constants

 xen/arch/arm/time.c | 36 
 xen/arch/arm/traps.c|  6 ++
 xen/include/xen/timer.h |  2 ++
 3 files changed, 44 insertions(+)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index c11fcfeadd..c0ae781ecd 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -263,6 +263,42 @@ static void vtimer_interrupt(int irq, void *dev_id, struct 
cpu_user_regs *regs)
 vgic_inject_irq(current->domain, current, current->arch.virt_timer.irq, 
true);
 }
 
+/**
+ * vtimer_sync() - update the state of the virtual timer after a guest run
+ * @vcpu: The VCPU to sync the arch timer state
+ *
+ * After returning from a guest, update the state of the virtual interrupt
+ * line, to model the level triggered interrupt correctly.
+ * If the guest has handled a timer interrupt, the virtual interrupt line
+ * needs to be lowered explicitly. vgic_inject_irq() takes care of that.
+ */
+void vtimer_sync(struct vcpu *vcpu)
+{
+struct vtimer *vtimer = &vcpu->arch.virt_timer;
+uint32_t vtimer_ctl = READ_SYSREG32(CNTV_CTL_EL0);
+bool level;
+
+/*
+ * Technically the mask should include the CNTx_CTL_MASK bit here,
+ * to catch if the timer interrupt is masked. However Xen always masks
+ * the timer upon entering the hypervisor, leaving it up to the guest
+ * to un-mask it. So we would always read a "low" level, despite the
+ * condition being actually "high".
+ * Ignoring the mask bit solves this (for now).
+ * Another possible check would be to compare the value of CNTVCT_EL0
+ * against vtimer->cval and derive the interrupt state from that.
+ */
+vtimer_ctl &= (CNTx_CTL_ENABLE | CNTx_CTL_PENDING);
+level = (vtimer_ctl == (CNTx_CTL_ENABLE | CNTx_CTL_PENDING));
+
+ /*
+  * TODO: The proper fix for this is to make vtimer vIRQ hardware mapped,
+  * but this requires reworking the arch timer to implement this.
+  */
+
+vgic_inject_irq(vcpu->domain, vcpu, vtimer->irq, level);
+}
+
 /*
  * Arch timer interrupt really ought to be level triggered, since the
  * design of the timer/comparator mechanism is based around that
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7411bff7a7..0713723bb7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,6 +2024,12 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
 if ( current->arch.hcr_el2 & HCR_VA )
 current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
 
+/*
+ * We need to update the state of our emulated devices using level
+ * triggered interrupts before syncing back the VGIC state.
+ */
+vtimer_sync(current);
+
 vgic_sync_from_lrs(current);
 }
 }
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index 4513260b0d..eddbbf3903 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -94,6 +94,8 @@ DECLARE_PER_CPU(s_time_t, timer_deadline);
 /* Arch-defined function to reprogram timer hardware for new deadline. */
 int reprogram_timer(s_time_t timeout);
 
+void vtimer_sync(struct vcpu *vcpu);
+
 /* Calculate the aligned first tick time for a given periodic timer. */
 s_time_t align_timer(s_time_t firsttick, uint64_t period);
 
-- 
2.14.1


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

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

[Andre Przywara]

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

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

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

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 5246d7c2e7..5bbf55da21 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -698,6 +698,77 @@ void vgic_kick_vcpus(struct domain *d)
 }
 }
 
+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
+  unsigned int virq)
+{
+struct irq_desc *desc = NULL;
+struct vgic_irq *irq = vgic_get_irq(d, v, virq);
+unsigned long flags;
+
+if ( !irq )
+return NULL;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+if ( irq->hw )
+{
+ASSERT(irq->hwintid >= VGIC_NR_PRIVATE_IRQS);
+desc = irq_to_desc(irq->hwintid);
+}
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+
+vgic_put_irq(d, irq);
+
+return desc;
+}
+
+/*
+ * was:
+ *  int kvm_vgic_map_phys_irq(struct vcpu *vcpu, u32 virt_irq, u32 
phys_irq)
+ *  int kvm_vgic_unmap_phys_irq(struct vcpu *vcpu, unsigned int virt_irq)
+ */
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *vcpu,
+unsigned int virt_irq, struct irq_desc *desc,
+bool connect)
+{
+struct vgic_irq *irq = vgic_get_irq(d, vcpu, virt_irq);
+unsigned long flags;
+int ret = 0;
+
+if ( !irq )
+return -EINVAL;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+if ( connect )  /* assign a mapped IRQ */
+{
+/* The VIRQ should not be already enabled by the guest */
+if ( !irq->hw && !irq->enabled )
+{
+irq->hw = true;
+irq->hwintid = desc->irq;
+}
+else
+ret = -EBUSY;
+}
+else/* remove a mapped IRQ */
+{
+if ( desc && irq->hwintid != desc->irq )
+{
+ret = -EINVAL;
+}
+else
+{
+irq->hw = false;
+irq->hwintid = 0;
+}
+}
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(d, irq);
+
+return ret;
+}
+
 static unsigned int translate_irq_type(bool is_level)
 {
 return is_level ? IRQ_TYPE_LEVEL_HIGH : IRQ_TYPE_EDGE_RISING;
-- 
2.14.1


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

[Xen-devel] [PATCH 29/57] ARM: new VGIC: Implement virtual IRQ injection

[Andre Przywara]

Provide a vgic_queue_irq_unlock() function which decides whether a
given IRQ needs to be queued to a VCPU's ap_list.
This should be called whenever an IRQ becomes pending or enabled,
either as a result of a hardware IRQ injection, from devices emulated by
Xen (like the architected timer) or from MMIO accesses to the distributor
emulation.
Also provides the necessary functions to allow to inject an IRQ to a guest.
Since this is the first code that starts using our locking mechanism,
we add some (hopefully) clear documentation of our locking strategy and
requirements along with this patch.

This is based on Linux commit 81eeb95ddbab, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- fix locking order comment
- adapt to former changes
- extend comments
- use kick_vcpu()

 xen/arch/arm/vgic/vgic.c | 227 +++
 xen/arch/arm/vgic/vgic.h |  10 +++
 2 files changed, 237 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index ace30f78d0..ae922815bd 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -21,6 +21,31 @@
 
 #include "vgic.h"
 
+/*
+ * Locking order is always:
+ *   vgic->lock
+ * vgic_cpu->ap_list_lock
+ *   vgic->lpi_list_lock
+ * desc->lock
+ *   vgic_irq->irq_lock
+ *
+ * If you need to take multiple locks, always take the upper lock first,
+ * then the lower ones, e.g. first take the ap_list_lock, then the irq_lock.
+ * If you are already holding a lock and need to take a higher one, you
+ * have to drop the lower ranking lock first and re-acquire it after having
+ * taken the upper one.
+ *
+ * When taking more than one ap_list_lock at the same time, always take the
+ * lowest numbered VCPU's ap_list_lock first, so:
+ *   vcpuX->vcpu_id < vcpuY->vcpu_id:
+ * spin_lock(vcpuX->arch.vgic.ap_list_lock);
+ * spin_lock(vcpuY->arch.vgic.ap_list_lock);
+ *
+ * Since the VGIC must support injecting virtual interrupts from ISRs, we have
+ * to use the spin_lock_irqsave/spin_unlock_irqrestore versions of outer
+ * spinlocks for any lock that may be taken while injecting an interrupt.
+ */
+
 /*
  * Iterate over the VM's list of mapped LPIs to find the one with a
  * matching interrupt ID and return a reference to the IRQ structure.
@@ -114,6 +139,208 @@ void vgic_put_irq(struct domain *d, struct vgic_irq *irq)
 xfree(irq);
 }
 
+/**
+ * vgic_target_oracle() - compute the target vcpu for an irq
+ * @irq:The irq to route. Must be already locked.
+ *
+ * Based on the current state of the interrupt (enabled, pending,
+ * active, vcpu and target_vcpu), compute the next vcpu this should be
+ * given to. Return NULL if this shouldn't be injected at all.
+ *
+ * Requires the IRQ lock to be held.
+ *
+ * Returns: The pointer to the virtual CPU this interrupt should be injected
+ *  to. Will be NULL if this IRQ does not need to be injected.
+ */
+static struct vcpu *vgic_target_oracle(struct vgic_irq *irq)
+{
+ASSERT(spin_is_locked(&irq->irq_lock));
+
+/* If the interrupt is active, it must stay on the current vcpu */
+if ( irq->active )
+return irq->vcpu ? : irq->target_vcpu;
+
+/*
+ * If the IRQ is not active but enabled and pending, we should direct
+ * it to its configured target VCPU.
+ * If the distributor is disabled, pending interrupts shouldn't be
+ * forwarded.
+ */
+if ( irq->enabled && irq_is_pending(irq) )
+{
+if ( unlikely(irq->target_vcpu &&
+  !irq->target_vcpu->domain->arch.vgic.enabled) )
+return NULL;
+
+return irq->target_vcpu;
+}
+
+/*
+ * If neither active nor pending and enabled, then this IRQ should not
+ * be queued to any VCPU.
+ */
+return NULL;
+}
+
+/*
+ * Only valid injection if changing level for level-triggered IRQs or for a
+ * rising edge.
+ */
+static bool vgic_validate_injection(struct vgic_irq *irq, bool level)
+{
+if ( irq->config == VGIC_CONFIG_LEVEL )
+return irq->line_level != level;
+
+return level;
+}
+
+/**
+ * vgic_queue_irq_unlock() - Queue an IRQ to a VCPU, to be injected to a guest.
+ * @d:The domain the virtual IRQ belongs to.
+ * @irq:  A pointer to the vgic_irq of the virtual IRQ, with the lock held.
+ * @flags:The flags used when having grabbed the IRQ lock.
+ *
+ * Check whether an IRQ needs to (and can) be queued to a VCPU's ap list.
+ * Do the queuing if necessary, taking the right locks in the right order.
+ *
+ * Needs to be entered with the IRQ lock already held, but will return
+ * with all locks dropped.
+ *
+ * Returns: True when the IRQ was queued, false otherwise.
+ */
+void vgic_queue_irq_unlock(struct domain *d, struct vgic_irq *irq,
+   unsigned long flags)
+{
+struct vcpu *vcpu;
+
+ASSERT(spin_is_locked(&irq->irq_lock));
+
+retry:
+vcpu = vgic_target_oracle(irq);
+if ( irq->vcpu || !vcp

[Xen-devel] [PATCH 25/57] ARM: evtchn: Handle level triggered IRQs correctly

[Andre Przywara]

The event channel IRQ has level triggered semantics, however the current
VGIC treats everything as edge triggered.
To correctly process those IRQs, we have to lower the (virtual) IRQ line
at some point in time, depending on whether ther interrupt condition
still prevails.
Check the per-VCPU evtchn_upcall_pending variable to make the interrupt
line match its status, and call this function upon every hypervisor
entry.

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

 xen/arch/arm/domain.c   | 7 +++
 xen/arch/arm/traps.c| 1 +
 xen/include/asm-arm/event.h | 1 +
 3 files changed, 9 insertions(+)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a7bba3ad44..11a46aa27f 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -955,6 +955,13 @@ void vcpu_mark_events_pending(struct vcpu *v)
 vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
 }
 
+void vcpu_update_evtchn_irq(struct vcpu *v)
+{
+bool pending = vcpu_info(v, evtchn_upcall_pending);
+
+vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, pending);
+}
+
 /* The ARM spec declares that even if local irqs are masked in
  * the CPSR register, an irq should wake up a cpu from WFI anyway.
  * For this reason we need to check for irqs that need delivery,
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0713723bb7..fcf5db50ae 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2029,6 +2029,7 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
  * triggered interrupts before syncing back the VGIC state.
  */
 vtimer_sync(current);
+vcpu_update_evtchn_irq(current);
 
 vgic_sync_from_lrs(current);
 }
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index c4c79fa87d..eafb2e7f3e 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -6,6 +6,7 @@
 
 void vcpu_kick(struct vcpu *v);
 void vcpu_mark_events_pending(struct vcpu *v);
+void vcpu_update_evtchn_irq(struct vcpu *v);
 void vcpu_block_unless_event_pending(struct vcpu *v);
 
 static inline int vcpu_event_delivery_is_enabled(struct vcpu *v)
-- 
2.14.1


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

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

[Andre Przywara]

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

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

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

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 2a2b8fd1eb..e1952c872d 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -813,6 +813,13 @@ struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, 
struct vcpu *v,
 return desc;
 }
 
+bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
+{
+ASSERT(current->domain->arch.vgic.version == GIC_V3);
+
+return false;
+}
+
 /*
  * was:
  *  int kvm_vgic_map_phys_irq(struct vcpu *vcpu, u32 virt_irq, u32 
phys_irq)
-- 
2.14.1


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

[Xen-devel] [PATCH 08/57] ARM: VGIC: Move gic_remove_from_lr_pending() prototype

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
Changelog RFC ... v1:
- Add Julien's Reviewed-by:

 xen/include/asm-arm/domain.h | 1 +
 xen/include/asm-arm/gic.h| 2 --
 xen/include/asm-arm/vgic.h   | 1 +
 3 files changed, 2 insertions(+), 2 deletions(-)

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


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

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

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- use proper locking
- use one header line to announce active or pending IRQs

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

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index e9ef992e1e..2a2b8fd1eb 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -765,6 +765,31 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
 clear_bit(virq, d->arch.vgic.allocated_irqs);
 }
 
+void gic_dump_vgic_info(struct vcpu *v)
+{
+struct vgic_cpu *vgic_cpu = &v->arch.vgic;
+struct vgic_irq *irq;
+unsigned long flags;
+
+spin_lock_irqsave(&v->arch.vgic.ap_list_lock, flags);
+
+if ( !list_empty(&vgic_cpu->ap_list_head) )
+printk("   active or pending interrupts queued:\n");
+
+list_for_each_entry ( irq, &vgic_cpu->ap_list_head, ap_list )
+{
+spin_lock(&irq->irq_lock);
+printk(" %s %s irq %u: %spending, %sactive, %senabled\n",
+   irq->hw ? "hardware" : "virtual",
+   irq->config == VGIC_CONFIG_LEVEL ? "level" : "edge",
+   irq->intid, irq_is_pending(irq) ? "" : "not ",
+   irq->active ? "" : "not ", irq->enabled ? "" : "not ");
+spin_unlock(&irq->irq_lock);
+}
+
+spin_unlock_irqrestore(&v->arch.vgic.ap_list_lock, flags);
+}
+
 struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
   unsigned int virq)
 {
-- 
2.14.1


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

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

[Andre Przywara]

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

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- drop unneeded vgic_vmcr initialization
- use update_hcr_status wrapper

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

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


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

[Xen-devel] [PATCH 27/57] ARM: new VGIC: Add data structure definitions

[Andre Przywara]

Add a new header file for the new and improved GIC implementation.
The big change is that we now have a struct vgic_irq per IRQ instead
of spreading all the information over various bitmaps in the ranks.

We include this new header conditionally from within the old header
file for the time being to avoid touching all the users.

This is based on Linux commit b18b57787f5e, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- rename header file to new_vgic.h
- drop unneeded data structures (vgic_its, vgic_v_cpu_if)
- reorder members in vgic_irq to avoid padding
- move flags members into bool bitfields
- drop prototypes
- use unsigned and uint_t data types
- keep arch_vcpu member name as "vgic"

 xen/include/asm-arm/new_vgic.h | 198 +
 xen/include/asm-arm/vgic.h |   6 ++
 2 files changed, 204 insertions(+)
 create mode 100644 xen/include/asm-arm/new_vgic.h

diff --git a/xen/include/asm-arm/new_vgic.h b/xen/include/asm-arm/new_vgic.h
new file mode 100644
index 00..54be5aa3eb
--- /dev/null
+++ b/xen/include/asm-arm/new_vgic.h
@@ -0,0 +1,198 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_ARM_NEW_VGIC_H
+#define __ASM_ARM_NEW_VGIC_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VGIC_V3_MAX_CPUS255
+#define VGIC_V2_MAX_CPUS8
+#define VGIC_NR_SGIS16
+#define VGIC_NR_PPIS16
+#define VGIC_NR_PRIVATE_IRQS(VGIC_NR_SGIS + VGIC_NR_PPIS)
+#define VGIC_MAX_PRIVATE(VGIC_NR_PRIVATE_IRQS - 1)
+#define VGIC_MAX_SPI1019
+#define VGIC_MAX_RESERVED   1023
+#define VGIC_MIN_LPI8192
+
+#define irq_is_ppi(irq) ((irq) >= VGIC_NR_SGIS && (irq) < VGIC_NR_PRIVATE_IRQS)
+#define irq_is_spi(irq) ((irq) >= VGIC_NR_PRIVATE_IRQS && \
+ (irq) <= VGIC_MAX_SPI)
+
+enum vgic_type {
+VGIC_V2,/* Good ol' GICv2 */
+VGIC_V3,/* New fancy GICv3 */
+};
+
+#define VGIC_V2_MAX_LRS (1 << 6)
+#define VGIC_V3_MAX_LRS 16
+#define VGIC_V3_LR_INDEX(lr)(VGIC_V3_MAX_LRS - 1 - lr)
+
+enum vgic_irq_config {
+VGIC_CONFIG_EDGE = 0,
+VGIC_CONFIG_LEVEL
+};
+
+struct vgic_irq {
+struct list_head ap_list;
+
+struct vcpu *vcpu;  /*
+ * SGIs and PPIs: The VCPU
+ * SPIs and LPIs: The VCPU whose ap_list
+ * this is queued on.
+ */
+
+struct vcpu *target_vcpu;   /*
+ * The VCPU that this interrupt should
+ * be sent to, as a result of the
+ * targets reg (v2) or the affinity reg (v3).
+ */
+
+spinlock_t irq_lock;/* Protects the content of the struct */
+uint32_t intid; /* Guest visible INTID */
+atomic_t refcount;  /* Used for LPIs */
+uint32_t hwintid;   /* HW INTID number */
+union
+{
+struct {
+uint8_t targets;/* GICv2 target VCPUs mask */
+uint8_t source; /* GICv2 SGIs only */
+};
+uint32_t mpidr; /* GICv3 target VCPU */
+};
+uint8_t priority;
+bool line_level:1;  /* Level only */
+bool pending_latch:1;   /*
+ * The pending latch state used to
+ * calculate the pending state for both
+ * level and edge triggered IRQs.
+ */
+bool active:1;  /* not used for LPIs */
+bool enabled:1;
+bool hw:1;  /* Tied to HW IRQ */
+bool config:1;  /* Level or edge */
+struct list_head lpi_list;  /* Used to link all LPIs together */
+};
+
+struct vgic_register_region;
+
+enum iodev_type {
+IODEV_DIST,
+IODEV_REDIST,
+};
+
+struct vgic_io_device {
+gfn_t base_fn;
+struct vcpu *redist_vcpu;
+const struct vgic_register_region *regions;
+enum iodev_type iodev_type;
+unsigned int nr_regions;
+};
+
+struct vgic_dist {
+boolready;
+boolinitialized;
+
+/* vGIC model the kernel emulates for the guest (GICv2 or GICv3) */
+uint32_tversion;
+
+

[Xen-devel] [PATCH 23/57] ARM: GIC: allow reading pending state of a hardware IRQ

[Andre Przywara]

To synchronize level triggered interrupts which are mapped into a guest,
we need to update the virtual line level at certain points in time.
For a hardware mapped interrupt the GIC is the only place where we can
easily access this information.
Implement a gic_hw_operations member to return the pending state of a
particular interrupt. Due to hardware limitations this only works for
private interrupts of the current CPU, so there is no CPU field in the
prototype.
This adds gicv2/3_peek_irq() helper functions, to read a bit in a bitmap
spread over several MMIO registers.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- add gicv2/3_peek_irq() helpers
- use struct irq_desc* in the interface (instead of just the IRQ number)

 xen/arch/arm/gic-v2.c | 15 +++
 xen/arch/arm/gic-v3.c | 19 +++
 xen/arch/arm/gic.c|  5 +
 xen/include/asm-arm/gic.h |  5 +
 4 files changed, 44 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 74169b5633..48352f6499 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -241,6 +241,15 @@ static void gicv2_poke_irq(struct irq_desc *irqd, uint32_t 
offset)
 writel_gicd(1U << (irqd->irq % 32), offset + (irqd->irq / 32) * 4);
 }
 
+static bool gicv2_peek_irq(struct irq_desc *irqd, uint32_t offset)
+{
+uint32_t reg;
+
+reg = readl_gicd(offset + (irqd->irq / 32) * 4) & (1U << (irqd->irq % 32));
+
+return reg;
+}
+
 static void gicv2_set_active_state(struct irq_desc *irqd, bool active)
 {
 ASSERT(spin_is_locked(&irqd->lock));
@@ -549,6 +558,11 @@ static unsigned int gicv2_read_apr(int apr_reg)
return readl_gich(GICH_APR);
 }
 
+static bool gicv2_read_pending_state(struct irq_desc *irqd)
+{
+return gicv2_peek_irq(irqd, GICD_ISPENDR);
+}
+
 static void gicv2_irq_enable(struct irq_desc *desc)
 {
 unsigned long flags;
@@ -1294,6 +1308,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .write_lr= gicv2_write_lr,
 .read_vmcr_priority  = gicv2_read_vmcr_priority,
 .read_apr= gicv2_read_apr,
+.read_pending_state  = gicv2_read_pending_state,
 .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
 .make_hwdom_madt = gicv2_make_hwdom_madt,
 .get_hwdom_extra_madt_size = gicv2_get_hwdom_extra_madt_size,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index c96469f09d..3e75d06c3b 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -444,6 +444,19 @@ static void gicv3_poke_irq(struct irq_desc *irqd, u32 
offset, bool wait_for_rwp)
 gicv3_wait_for_rwp(irqd->irq);
 }
 
+static bool gicv3_peek_irq(struct irq_desc *irqd, u32 offset)
+{
+void __iomem *base;
+unsigned int irq = irqd->irq;
+
+if ( irq >= NR_GIC_LOCAL_IRQS)
+base = GICD + (irq / 32) * 4;
+else
+base = GICD_RDIST_SGI_BASE;
+
+return !!(readl(base + offset) & (1U << (irq % 32)));
+}
+
 static void gicv3_unmask_irq(struct irq_desc *irqd)
 {
 gicv3_poke_irq(irqd, GICD_ISENABLER, false);
@@ -1094,6 +1107,11 @@ static unsigned int gicv3_read_apr(int apr_reg)
 }
 }
 
+static bool gicv3_read_pending_state(struct irq_desc *irqd)
+{
+return gicv3_peek_irq(irqd, GICD_ISPENDR);
+}
+
 static void gicv3_irq_enable(struct irq_desc *desc)
 {
 unsigned long flags;
@@ -1762,6 +1780,7 @@ static const struct gic_hw_operations gicv3_ops = {
 .write_lr= gicv3_write_lr,
 .read_vmcr_priority  = gicv3_read_vmcr_priority,
 .read_apr= gicv3_read_apr,
+.read_pending_state  = gicv3_read_pending_state,
 .secondary_init  = gicv3_secondary_cpu_init,
 .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
 .make_hwdom_madt = gicv3_make_hwdom_madt,
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index f1329a630a..67c3b4d86d 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -116,6 +116,11 @@ static void gic_set_irq_priority(struct irq_desc *desc, 
unsigned int priority)
 gic_hw_ops->set_irq_priority(desc, priority);
 }
 
+bool gic_read_pending_state(struct irq_desc *irqd)
+{
+return gic_hw_ops->read_pending_state(irqd);
+}
+
 /* Program the GIC to route an interrupt to the host (i.e. Xen)
  * - needs to be called with desc.lock held
  */
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 46dcb0fe7c..03667f00cf 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -248,6 +248,9 @@ void gic_set_pending_state(struct irq_desc *irqd, bool 
state);
 /* Program the IRQ type into the GIC */
 void gic_set_irq_type(struct irq_desc *desc, unsigned int type);
 
+/* Read the pending state of an interrupt from the distributor. */
+bool gic_read_pending_state(struct irq_desc *irqd);
+
 /* Program the GIC to route an interrupt */
 extern void gic_route_irq_to_xen(struct irq_desc *desc, unsigned int priority);
 extern int gic_route_irq_to_guest(struct domain *, unsigned int virq,
@@ -382,6 +385,8 @@ struct gic_hw_

[Xen-devel] [PATCH 39/57] ARM: new VGIC: Add ACTIVE registers handlers

[Andre Przywara]

The active register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
Since activation/deactivation of an interrupt may happen entirely in the
guest without it ever exiting, we need some extra logic to properly track
the active state.
For clearing the active state, we would basically have to halt the guest
to make sure this is properly propagated into the respective VCPUs.
This is not yet implemented in Xen.
Fortunately this feature is mostly used to reset a just in initialised
GIC, so chances are we are tasked to clear bits that are already zero.
Add some simple check to avoid a pointless warning in this case.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- remove premature "proper ACTIVE" handler stub
- avoid unnecessary warnings on NO-OP register writes
- extend comments

 xen/arch/arm/vgic/vgic-mmio-v2.c |   4 +-
 xen/arch/arm/vgic/vgic-mmio.c| 103 +++
 xen/arch/arm/vgic/vgic-mmio.h|  11 +
 3 files changed, 116 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index efdd73301d..c93455fbb2 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -92,10 +92,10 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_pending, vgic_mmio_write_cpending, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISACTIVER,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_active, vgic_mmio_write_sactive, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICACTIVER,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_active, vgic_mmio_write_cactive, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IPRIORITYR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index 2e939d5e39..c44d67082f 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -281,6 +281,109 @@ void vgic_mmio_write_cpending(struct vcpu *vcpu,
 }
 }
 
+/*
+ * The actual active bit for a virtual IRQ is held in the LR. Our shadow
+ * copy in struct vgic_irq is only synced when needed and may not be
+ * up-to-date all of the time.
+ * Returning the actual active state is quite costly (stopping all
+ * VCPUs processing any affected vIRQs), so we use a simple implementation
+ * to get the best possible answer.
+ */
+unsigned long vgic_mmio_read_active(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+uint32_t value = 0;
+unsigned int i;
+
+/* Loop over all IRQs affected by this read */
+for ( i = 0; i < len * 8; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+if ( irq->active )
+value |= (1U << i);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return value;
+}
+
+/*
+ * We don't actually support clearing the active state of an IRQ (yet).
+ * However there is a chance that most guests use this for initialization.
+ * We check whether this MMIO access would actually affect any active IRQ,
+ * and only print our warning in this case. So clearing already non-active
+ * IRQs would not be moaned about in the logs.
+ */
+void vgic_mmio_write_cactive(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+bool bail_out = false;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+/*
+ * If we know that the IRQ is active or we can't be sure about
+ * it (because it is currently in a CPU), log the not properly
+ * emulated MMIO access.
+ */
+if ( irq->active || irq->vcpu )
+{
+gdprintk(XENLOG_ERR,
+ "%pv: vGICD: IRQ%d: clearing active state not 
supported\n",
+ vcpu, irq->intid);
+bail_out = true;
+}
+
+vgic_put_irq(vcpu->domain, irq);
+if ( bail_out )
+return;
+}
+}
+
+/*
+ * We don't actually support setting the active state of an IRQ (yet).
+ * We check whether this MMIO access would actually affect any non-active IRQ,
+ * and only print our warning in this case.
+ */
+void vgic_mmio_write_sactive(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+bool bail_out = false;
+
+for_each_set_bit( i, &val, len * 8 )
+

[Xen-devel] [PATCH 36/57] ARM: new VGIC: Add CTLR, TYPER and IIDR handlers

[Andre Przywara]

Those three registers are v2 emulation specific, so their implementation
lives entirely in vgic-mmio-v2.c. Also they are handled in one function,
as their implementation is pretty simple.
When the guest enables the distributor, we kick all VCPUs to get
potentially pending interrupts serviced.

This is based on Linux commit 2b0cda878965, written by Marc Zyngier.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- use PRODUCT_ID_XEN
- use proper locking on enabling VGIC
- use kick_vcpu()

 xen/arch/arm/vgic/vgic-mmio-v2.c | 54 +++-
 xen/arch/arm/vgic/vgic.c | 15 +++
 xen/arch/arm/vgic/vgic.h |  4 +++
 3 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 6f10cf16ca..2e015ed0b1 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -20,9 +20,61 @@
 #include "vgic.h"
 #include "vgic-mmio.h"
 
+static unsigned long vgic_mmio_read_v2_misc(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t value;
+
+switch ( addr & 0x0c )  /* filter for the 4 registers handled here */
+{
+case GICD_CTLR:
+value = vcpu->domain->arch.vgic.enabled ? GICD_CTL_ENABLE : 0;
+break;
+case GICD_TYPER:
+value = vcpu->domain->arch.vgic.nr_spis + VGIC_NR_PRIVATE_IRQS;
+value = (value >> 5) - 1;
+value |= (vcpu->domain->max_vcpus - 1) << 5;
+break;
+case GICD_IIDR:
+value = (PRODUCT_ID_XEN << 24) | (IMPLEMENTER_ARM << 0);
+break;
+default:
+return 0;
+}
+
+return value;
+}
+
+static void vgic_mmio_write_v2_misc(struct vcpu *vcpu,
+paddr_t addr, unsigned int len,
+unsigned long val)
+{
+struct vgic_dist *dist = &vcpu->domain->arch.vgic;
+bool enabled;
+
+switch ( addr & 0x0c )  /* filter for the 4 registers handled here */
+{
+case GICD_CTLR:
+domain_lock(vcpu->domain);
+enabled = dist->enabled;
+dist->enabled = val & GICD_CTL_ENABLE;
+enabled = !enabled && dist->enabled;
+domain_unlock(vcpu->domain);
+
+if (enabled)
+vgic_kick_vcpus(vcpu->domain);
+
+break;
+case GICD_TYPER:
+case GICD_IIDR:
+/* read-only, writes ignored */
+return;
+}
+}
+
 static const struct vgic_register_region vgic_v2_dist_registers[] = {
 REGISTER_DESC_WITH_LENGTH(GICD_CTLR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 12,
+vgic_mmio_read_v2_misc, vgic_mmio_write_v2_misc, 12,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IGROUPR,
 vgic_mmio_read_rao, vgic_mmio_write_wi, 1,
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 66a366176a..465a95f415 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -683,6 +683,21 @@ int vgic_pending_irq(void)
 return vgic_vcpu_pending_irq(current);
 }
 
+void vgic_kick_vcpus(struct domain *d)
+{
+struct vcpu *vcpu;
+
+/*
+ * We've injected an interrupt, time to find out who deserves
+ * a good kick...
+ */
+for_each_vcpu( d, vcpu )
+{
+if ( vgic_vcpu_pending_irq(vcpu) )
+kick_vcpu(vcpu);
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index 632b246e93..588bd067b7 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -17,6 +17,9 @@
 #ifndef __XEN_ARM_VGIC_VGIC_H__
 #define __XEN_ARM_VGIC_VGIC_H__
 
+#define PRODUCT_ID_XEN  0x58/* ASCII code X */
+#define IMPLEMENTER_ARM 0x43b
+
 #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
 
 static inline bool irq_is_pending(struct vgic_irq *irq)
@@ -37,6 +40,7 @@ struct vgic_irq *vgic_get_irq(struct domain *d, struct vcpu 
*vcpu,
 void vgic_put_irq(struct domain *d, struct vgic_irq *irq);
 void vgic_queue_irq_unlock(struct domain *d, struct vgic_irq *irq,
unsigned long flags);
+void vgic_kick_vcpus(struct domain *d);
 
 static inline void vgic_get_irq_kref(struct vgic_irq *irq)
 {
-- 
2.14.1


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

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

[Andre Przywara]

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

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

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

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


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

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

[Andre Przywara]

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

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

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

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

diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
index 4e74ebf7f5..da64b4758c 100644
--- a/xen/arch/arm/vgic/vgic-v2.c
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -221,6 +221,72 @@ void vgic_v2_populate_lr(struct vcpu *vcpu, struct 
vgic_irq *irq, int lr)
 gic_hw_ops->write_lr(lr, &lr_val);
 }
 
+int vgic_v2_map_resources(struct domain *d)
+{
+struct vgic_dist *dist = &d->arch.vgic;
+paddr_t cbase, csize;
+paddr_t vbase;
+int ret;
+
+/*
+ * The hardware domain gets the hardware address.
+ * Guests get the virtual platform layout.
+ */
+if ( is_hardware_domain(d) )
+{
+d->arch.vgic.vgic_dist_base = gic_v2_hw_data.dbase;
+/*
+ * For the hardware domain, we always map the whole HW CPU
+ * interface region in order to match the device tree (the "reg"
+ * properties is copied as it is).
+ * Note that we assume the size of the CPU interface is always
+ * aligned to PAGE_SIZE.
+ */
+cbase = gic_v2_hw_data.cbase;   /* was: dist->vgic_cpu_base */
+csize = gic_v2_hw_data.csize;
+vbase = gic_v2_hw_data.vbase; /* was: kvm_vgic_global_state.vcpu_base 
*/
+}
+else
+{
+d->arch.vgic.vgic_dist_base = GUEST_GICD_BASE;
+/*
+ * The CPU interface exposed to the guest is always 8kB. We may
+ * need to add an offset to the virtual CPU interface base
+ * address when in the GIC is aliased to get a 8kB contiguous
+ * region.
+ */
+BUILD_BUG_ON(GUEST_GICC_SIZE != SZ_8K);
+cbase = GUEST_GICC_BASE;
+csize = GUEST_GICC_SIZE;
+vbase = gic_v2_hw_data.vbase + gic_v2_hw_data.aliased_offset;
+}
+
+
+ret = vgic_register_dist_iodev(d, gaddr_to_gfn(dist->vgic_dist_base),
+   VGIC_V2);
+if ( ret )
+{
+gdprintk(XENLOG_ERR, "Unable to register VGIC MMIO regions\n");
+return ret;
+}
+
+/*
+ * Map the gic virtual cpu interface in the gic cpu interface
+ * region of the guest.
+ */
+ret = map_mmio_regions(d, gaddr_to_gfn(cbase), csize / PAGE_SIZE,
+   maddr_to_mfn(vbase));
+if ( ret )
+{
+gdprintk(XENLOG_ERR, "Unable to remap VGIC CPU to VCPU\n");
+return ret;
+}
+
+dist->ready = true;
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index f19dc9502f..6fab994b9c 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -61,6 +61,7 @@ void vgic_sync_hardware_irq(struct domain *d,
 void vgic_v2_fold_lr_state(struct vcpu *vcpu);
 void vgic_v2_populate_lr(struct vcpu *vcpu, struct vgic_irq *irq, int lr);
 void vgic_v2_set_underflow(struct vcpu *vcpu);
+int vgic_v2_map_resources(struct domain *d);
 int vgic_register_dist_iodev(struct domain *d, gfn_t dist_base_fn,
  enum vgic_type);
 
-- 
2.14.1


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

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

[Andre Przywara]

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

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

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

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 5bbf55da21..0bf257c865 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -698,6 +698,29 @@ void vgic_kick_vcpus(struct domain *d)
 }
 }
 
+void arch_evtchn_inject(struct vcpu *v)
+{
+vgic_inject_irq(v->domain, v, v->domain->arch.evtchn_irq, true);
+}
+
+bool vgic_evtchn_irq_pending(struct vcpu *v)
+{
+struct vgic_irq *irq;
+unsigned long flags;
+bool pending;
+
+/* Does not work for LPIs. */
+ASSERT(!is_lpi(v->domain->arch.evtchn_irq));
+
+irq = vgic_get_irq(v->domain, v, v->domain->arch.evtchn_irq);
+spin_lock_irqsave(&irq->irq_lock, flags);
+pending = irq_is_pending(irq);
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(v->domain, irq);
+
+return pending;
+}
+
 struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
   unsigned int virq)
 {
-- 
2.14.1


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

[Xen-devel] [PATCH 31/57] ARM: new VGIC: Add IRQ sync/flush framework

[Andre Przywara]

Implement the framework for syncing IRQs between our emulation and the
list registers, which represent the guest's view of IRQs.
This is done in kvm_vgic_flush_hwstate and kvm_vgic_sync_hwstate, which
gets called on guest entry and exit.
The code talking to the actual GICv2/v3 hardware is added in the
following patches.

This is based on Linux commit 0919e84c0fc1, written by Marc Zyngier.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- extend comments
- adapt to former changes
- remove gic_clear_lrs()

 xen/arch/arm/vgic/vgic.c | 239 +++
 xen/arch/arm/vgic/vgic.h |   2 +
 2 files changed, 241 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index efa6c67cb7..8e5215a00d 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -400,6 +400,245 @@ int vgic_inject_irq(struct domain *d, struct vcpu *vcpu, 
unsigned int intid,
 return 0;
 }
 
+/**
+ * vgic_prune_ap_list() - Remove non-relevant interrupts from the ap_list
+ *
+ * @vcpu:   The VCPU of which the ap_list should be pruned.
+ *
+ * Go over the list of interrupts on a VCPU's ap_list, and prune those that
+ * we won't have to consider in the near future.
+ * This removes interrupts that have been successfully handled by the guest,
+ * or that have otherwise became obsolete (not pending anymore).
+ * Also this moves interrupts between VCPUs, if their affinity has changed.
+ */
+static void vgic_prune_ap_list(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+struct vgic_irq *irq, *tmp;
+unsigned long flags;
+
+retry:
+spin_lock_irqsave(&vgic_cpu->ap_list_lock, flags);
+
+list_for_each_entry_safe( irq, tmp, &vgic_cpu->ap_list_head, ap_list )
+{
+struct vcpu *target_vcpu, *vcpuA, *vcpuB;
+
+spin_lock(&irq->irq_lock);
+
+BUG_ON(vcpu != irq->vcpu);
+
+target_vcpu = vgic_target_oracle(irq);
+
+if ( !target_vcpu )
+{
+/*
+ * We don't need to process this interrupt any
+ * further, move it off the list.
+ */
+list_del(&irq->ap_list);
+irq->vcpu = NULL;
+spin_unlock(&irq->irq_lock);
+
+/*
+ * This vgic_put_irq call matches the
+ * vgic_get_irq_kref in vgic_queue_irq_unlock,
+ * where we added the LPI to the ap_list. As
+ * we remove the irq from the list, we drop
+ * also drop the refcount.
+ */
+vgic_put_irq(vcpu->domain, irq);
+continue;
+}
+
+if ( target_vcpu == vcpu )
+{
+/* We're on the right CPU */
+spin_unlock(&irq->irq_lock);
+continue;
+}
+
+/* This interrupt looks like it has to be migrated. */
+
+spin_unlock(&irq->irq_lock);
+spin_unlock_irqrestore(&vgic_cpu->ap_list_lock, flags);
+
+/*
+ * Ensure locking order by always locking the smallest
+ * ID first.
+ */
+if ( vcpu->vcpu_id < target_vcpu->vcpu_id )
+{
+vcpuA = vcpu;
+vcpuB = target_vcpu;
+}
+else
+{
+vcpuA = target_vcpu;
+vcpuB = vcpu;
+}
+
+spin_lock_irqsave(&vcpuA->arch.vgic.ap_list_lock, flags);
+spin_lock(&vcpuB->arch.vgic.ap_list_lock);
+spin_lock(&irq->irq_lock);
+
+/*
+ * If the affinity has been preserved, move the
+ * interrupt around. Otherwise, it means things have
+ * changed while the interrupt was unlocked, and we
+ * need to replay this.
+ *
+ * In all cases, we cannot trust the list not to have
+ * changed, so we restart from the beginning.
+ */
+if ( target_vcpu == vgic_target_oracle(irq) )
+{
+struct vgic_cpu *new_cpu = &target_vcpu->arch.vgic;
+
+list_del(&irq->ap_list);
+irq->vcpu = target_vcpu;
+list_add_tail(&irq->ap_list, &new_cpu->ap_list_head);
+}
+
+spin_unlock(&irq->irq_lock);
+spin_unlock(&vcpuB->arch.vgic.ap_list_lock);
+spin_unlock_irqrestore(&vcpuA->arch.vgic.ap_list_lock, flags);
+goto retry;
+}
+
+spin_unlock_irqrestore(&vgic_cpu->ap_list_lock, flags);
+}
+
+static inline void vgic_fold_lr_state(struct vcpu *vcpu)
+{
+}
+
+/* Requires the irq_lock to be held. */
+static inline void vgic_populate_lr(struct vcpu *vcpu,
+struct vgic_irq *irq, int lr)
+{
+ASSERT(spin_is_locked(&irq->irq_lock));
+}
+
+static inline void vgic_set_underflow(struct vcpu *vcpu)
+{
+}
+
+/* Requires the ap_list_lock to be held. */
+static int compute_ap_list_depth(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+struct vgic_irq *irq;
+int count = 0;
+
+ASSERT(spin_is_locked(&vgic_cpu->ap_list_lock));
+
+li

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

[Andre Przywara]

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

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

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

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

diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
index d091c92ed0..8bc83f677b 100644
--- a/xen/arch/arm/vgic/vgic-init.c
+++ b/xen/arch/arm/vgic/vgic-init.c
@@ -20,6 +20,77 @@
 
 #include "vgic.h"
 
+/*
+ * Initialization rules: there are multiple stages to the vgic
+ * initialization, both for the distributor and the CPU interfaces.  The basic
+ * idea is that even though the VGIC is not functional or not requested from
+ * user space, the critical path of the run loop can still call VGIC functions
+ * that just won't do anything, without them having to check additional
+ * initialization flags to ensure they don't look at uninitialized data
+ * structures.
+ *
+ * Distributor:
+ *
+ * - vgic_early_init(): initialization of static data that doesn't
+ *   depend on any sizing information or emulation type. No allocation
+ *   is allowed there.
+ *
+ * - vgic_init(): allocation and initialization of the generic data
+ *   structures that depend on sizing information (number of CPUs,
+ *   number of interrupts). Also initializes the vcpu specific data
+ *   structures. Can be executed lazily for GICv2.
+ *
+ * CPU Interface:
+ *
+ * - kvm_vgic_vcpu_early_init(): initialization of static data that
+ *   doesn't depend on any sizing information or emulation type. No
+ *   allocation is allowed there.
+ */
+
+/**
+ * vgic_vcpu_early_init() - Initialize static VGIC VCPU data structures
+ * @vcpu: The VCPU whose VGIC data structures whould be initialized
+ *
+ * Only do initialization, but do not actually enable the VGIC CPU interface
+ * yet.
+ */
+static void vgic_vcpu_early_init(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+int i;
+
+INIT_LIST_HEAD(&vgic_cpu->ap_list_head);
+spin_lock_init(&vgic_cpu->ap_list_lock);
+
+/*
+ * Enable and configure all SGIs to be edge-triggered and
+ * configure all PPIs as level-triggered.
+ */
+for ( i = 0; i < VGIC_NR_PRIVATE_IRQS; i++ )
+{
+struct vgic_irq *irq = &vgic_cpu->private_irqs[i];
+
+INIT_LIST_HEAD(&irq->ap_list);
+spin_lock_init(&irq->irq_lock);
+irq->intid = i;
+irq->vcpu = NULL;
+irq->target_vcpu = vcpu;
+irq->targets = 1U << vcpu->vcpu_id;
+atomic_set(&irq->refcount, 0);
+if ( vgic_irq_is_sgi(i) )
+{
+/* SGIs */
+irq->enabled = 1;
+irq->config = VGIC_CONFIG_EDGE;
+}
+else
+{
+/* PPIs */
+irq->config = VGIC_CONFIG_LEVEL;
+}
+}
+}
+
 /* CREATION */
 
 /**
@@ -50,6 +121,131 @@ int domain_vgic_register(struct domain *d, int *mmio_count)
 return 0;
 }
 
+/* INIT/DESTROY */
+
+/**
+ * domain_vgic_init: initialize the dist data structures
+ * @d: domain pointer
+ * @nr_spis: number of SPIs
+ */
+int domain_vgic_init(struct domain *d, unsigned int nr_spis)
+{
+struct vgic_dist *dist = &d->arch.vgic;
+int i, ret;
+
+/* Limit the number of virtual SPIs supported to (1020 - 32) = 988  */
+if ( nr_spis > (1020 - NR_LOCAL_IRQS) )
+return -EINVAL;
+
+dist->nr_spis = nr_spis;
+dist->spis = xzalloc_array(struct vgic_irq, nr_spis);
+if ( !dist->spis )
+return  -ENOMEM;
+
+/*
+ * In the following code we do not take the irq struct lock since
+ * no other action on irq structs can happen while the VGIC is
+ * not initialized yet:
+ * If someone wants to inject an interrupt or does a MMIO access, we
+ * require prior initialization in case of a virtual GICv3 or trigger
+ * initialization when using a virtual GICv2.
+ */
+for ( i = 0; i < nr_spis; i++ )
+{
+struct vgic_irq *irq = &dist->spis[i];
+
+irq->intid = i + VGIC_NR_PRIVATE_IRQS;
+INIT_LIST_HEAD(&irq->ap_list);
+spin_lock_init(&irq->irq_lock);
+irq->vcpu = NULL;
+irq->target_vcpu = NULL;
+atomic_set(&irq->refcount, 0);
+if ( dist->version == GIC_V2 )
+irq->targets = 0;
+else
+irq->mpidr = 0;
+}
+
+INIT_LIST_HEAD(&dist->lpi_list_head);
+spin_lock_init(&dist->lpi_list_lock);
+
+if ( dist->version == GIC_V2 )
+ret = vgic_v2_map_resources(d);
+else
+ret = -ENXIO;
+
+i

[Xen-devel] [PATCH 44/57] ARM: new VGIC: Add SGIPENDR register handlers

[Andre Przywara]

As this register is v2 specific, its implementation lives entirely
in vgic-mmio-v2.c.
This register allows setting the source mask of an IPI.

This is based on Linux commit ed40213ef9b0, written by Andre Przywara.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- use C99 and unsigned data types

 xen/arch/arm/vgic/vgic-mmio-v2.c | 81 +++-
 1 file changed, 79 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 5f1fdb9a70..dd9857e8a6 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -177,6 +177,83 @@ static void vgic_mmio_write_target(struct vcpu *vcpu,
 }
 }
 
+static unsigned long vgic_mmio_read_sgipend(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+uint32_t val = 0;
+unsigned int i;
+
+ASSERT(intid < VGIC_NR_SGIS);
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+val |= (uint32_t)irq->source << (i * 8);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return val;
+}
+
+static void vgic_mmio_write_sgipendc(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+unsigned int i;
+unsigned long flags;
+
+ASSERT(intid < VGIC_NR_SGIS);
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+irq->source &= ~((val >> (i * 8)) & 0xff);
+if ( !irq->source )
+irq->pending_latch = false;
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
+static void vgic_mmio_write_sgipends(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+unsigned int i;
+unsigned long flags;
+
+ASSERT(intid < VGIC_NR_SGIS);
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+irq->source |= (val >> (i * 8)) & 0xff;
+
+if ( irq->source )
+{
+irq->pending_latch = true;
+vgic_queue_irq_unlock(vcpu->domain, irq, flags);
+}
+else
+{
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+}
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
 static const struct vgic_register_region vgic_v2_dist_registers[] = {
 REGISTER_DESC_WITH_LENGTH(GICD_CTLR,
 vgic_mmio_read_v2_misc, vgic_mmio_write_v2_misc, 12,
@@ -215,10 +292,10 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_raz, vgic_mmio_write_sgir, 4,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_LENGTH(GICD_CPENDSGIR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
+vgic_mmio_read_sgipend, vgic_mmio_write_sgipendc, 16,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_LENGTH(GICD_SPENDSGIR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
+vgic_mmio_read_sgipend, vgic_mmio_write_sgipends, 16,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 };
 
-- 
2.14.1


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

[Xen-devel] [PATCH 28/57] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

[Andre Przywara]

The new VGIC implementation centers around a struct vgic_irq instance
per virtual IRQ.
Provide a function to retrieve the right instance for a given IRQ
number and (in case of private interrupts) the right VCPU.
This also includes the corresponding put function, which does nothing
for private interrupts and SPIs, but handles the ref-counting for LPIs.

This is based on Linux commit 64a959d66e47, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- add kernel-doc comments to exported functions
- adapt to previous changes (new_vgic.h, arch_vcpu member name)
- use ASSERT_UNREACHABLE

 xen/arch/arm/vgic/vgic.c | 124 +++
 xen/arch/arm/vgic/vgic.h |  41 
 2 files changed, 165 insertions(+)
 create mode 100644 xen/arch/arm/vgic/vgic.c
 create mode 100644 xen/arch/arm/vgic/vgic.h

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
new file mode 100644
index 00..ace30f78d0
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic.c
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include "vgic.h"
+
+/*
+ * Iterate over the VM's list of mapped LPIs to find the one with a
+ * matching interrupt ID and return a reference to the IRQ structure.
+ */
+static struct vgic_irq *vgic_get_lpi(struct domain *d, u32 intid)
+{
+struct vgic_dist *dist = &d->arch.vgic;
+struct vgic_irq *irq = NULL;
+
+spin_lock(&dist->lpi_list_lock);
+
+list_for_each_entry( irq, &dist->lpi_list_head, lpi_list )
+{
+if ( irq->intid != intid )
+continue;
+
+/*
+ * This increases the refcount, the caller is expected to
+ * call vgic_put_irq() later once it's finished with the IRQ.
+ */
+vgic_get_irq_kref(irq);
+goto out_unlock;
+}
+irq = NULL;
+
+out_unlock:
+spin_unlock(&dist->lpi_list_lock);
+
+return irq;
+}
+
+/**
+ * vgic_get_irq() - obtain a reference to a virtual IRQ
+ * @d:The domain the virtual IRQ belongs to.
+ * @vcpu: For private IRQs (SGIs, PPIs) the virtual CPU this IRQ
+ *is associated with. Will be ignored for SPIs and LPIs.
+ * @intid:The virtual IRQ number.
+ *
+ * This looks up the virtual interrupt ID to get the corresponding
+ * struct vgic_irq. It also increases the refcount, so any caller is expected
+ * to call vgic_put_irq() once it's finished with this IRQ.
+ *
+ * Return: The pointer to the requested struct vgic_irq.
+ */
+struct vgic_irq *vgic_get_irq(struct domain *d, struct vcpu *vcpu,
+  u32 intid)
+{
+/* SGIs and PPIs */
+if ( intid <= VGIC_MAX_PRIVATE )
+return &vcpu->arch.vgic.private_irqs[intid];
+
+/* SPIs */
+if ( intid <= VGIC_MAX_SPI )
+return &d->arch.vgic.spis[intid - VGIC_NR_PRIVATE_IRQS];
+
+/* LPIs */
+if ( intid >= VGIC_MIN_LPI )
+return vgic_get_lpi(d, intid);
+
+ASSERT_UNREACHABLE();
+}
+
+/**
+ * vgic_put_irq() - drop the reference to a virtual IRQ
+ * @d:The domain the virtual IRQ belongs to.
+ * @irq:  The pointer to struct vgic_irq, as obtained from vgic_get_irq().
+ *
+ * This drops the reference to a virtual IRQ. It decreases the refcount
+ * of the pointer, so dynamic IRQs can be freed when no longer needed.
+ * This should always be called after a vgic_get_irq(), though the reference
+ * can be deliberately held for longer periods, if needed.
+ */
+void vgic_put_irq(struct domain *d, struct vgic_irq *irq)
+{
+struct vgic_dist *dist = &d->arch.vgic;
+
+if ( irq->intid < VGIC_MIN_LPI )
+return;
+
+spin_lock(&dist->lpi_list_lock);
+if ( !atomic_dec_and_test(&irq->refcount) )
+{
+spin_unlock(&dist->lpi_list_lock);
+return;
+};
+
+list_del(&irq->lpi_list);
+dist->lpi_list_count--;
+spin_unlock(&dist->lpi_list_lock);
+
+xfree(irq);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
new file mode 100644
index 00..a3befd386b
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) 

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

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- new patch

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

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


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

[Xen-devel] [PATCH 05/57] ARM: vGICv3: always use architected redist stride

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
Changelog RFC ... v1:
- Add Julien's ACK

 xen/arch/arm/gic-v3.c  |  4 
 xen/arch/arm/vgic-v3.c | 14 ++
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index be1787b39a..02c85e4c0c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1164,10 +1164,6 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 if ( res )
 return res;
 
-res = fdt_property_cell(fdt, "redistributor-stride", gicv3.rdist_stride);
-if ( res )
-return res;
-
 res = fdt_property_cell(fdt, "#redistributor-regions", gicv3.rdist_count);
 if ( res )
 return res;
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d5b34a7d0f..56cc38ffcc 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1024,10 +1024,9 @@ static struct vcpu *get_vcpu_from_rdist(struct domain *d,
 paddr_t gpa, uint32_t *offset)
 {
 struct vcpu *v;
-uint32_t stride = d->arch.vgic.rdist_stride;
 unsigned int vcpu_id;
 
-vcpu_id = region->first_cpu + ((gpa - region->base) / stride);
+vcpu_id = region->first_cpu + ((gpa - region->base) / GICV3_GICR_SIZE);
 if ( unlikely(vcpu_id >= d->max_vcpus) )
 return NULL;
 
@@ -1586,7 +1585,6 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
 
 /* Convenient alias */
 struct domain *d = v->domain;
-uint32_t rdist_stride = d->arch.vgic.rdist_stride;
 
 /*
  * Find the region where the re-distributor lives. For this purpose,
@@ -1602,11 +1600,11 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
 
 /* Get the base address of the redistributor */
 rdist_base = region->base;
-rdist_base += (v->vcpu_id - region->first_cpu) * rdist_stride;
+rdist_base += (v->vcpu_id - region->first_cpu) * GICV3_GICR_SIZE;
 
 /* Check if a valid region was found for the re-distributor */
 if ( (rdist_base < region->base) ||
- ((rdist_base + rdist_stride) > (region->base + region->size)) )
+ ((rdist_base + GICV3_GICR_SIZE) > (region->base + region->size)) )
 {
 dprintk(XENLOG_ERR,
 "d%u: Unable to find a re-distributor for VCPU %u\n",
@@ -1622,7 +1620,7 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
  * VGIC_V3_RDIST_LAST flags.
  * Note that we are assuming max_vcpus will never change.
  */
-last_cpu = (region->size / rdist_stride) + region->first_cpu - 1;
+last_cpu = (region->size / GICV3_GICR_SIZE) + region->first_cpu - 1;
 
 if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
 v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;
@@ -1693,7 +1691,7 @@ static int vgic_v3_domain_init(struct domain *d)
 /* Set the first CPU handled by this region */
 d->arch.vgic.rdist_regions[i].first_cpu = first_cpu;
 
-first_cpu += size / d->arch.vgic.rdist_stride;
+first_cpu += size / GICV3_GICR_SIZE;
 }
 
 d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
@@ -1708,7 +1706,7 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
 
 /* The first redistributor should contain enough space for all CPUs */
-BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GUEST_GICV3_RDIST_STRIDE) < 
MAX_VIRT_CPUS);
+BUILD_BUG_ON((GUEST_GICV3_GICR0_SIZE / GICV3_GICR_SIZE) < 
MAX_VIRT_CPUS);
 d->arch.vgic.rdist_regions[0].base = GUEST_GICV3_GICR0_BASE;
 d->arch.vgic.rdist_regions[0].size = GUEST_GICV3_GICR0_SIZE;
 d->arch.vgic.rdist_regions[0].first_cpu = 0;
-- 
2.14.1


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

[Xen-devel] [PATCH 15/57] ARM: GICv2: Extend and adjust register definitions

[Andre Przywara]

The new VGIC will shortly use more bits of the various GIC registers, so
add the respective definitions from the manual.
This includes bits from the GICC_CTL register and some minor other bits.
Adjust the usage of ICC_CTL_ENABLE on the way, to be more precise about
which of the two enable bits we actually deal with.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- extend commit message

 xen/arch/arm/gic-v2.c |  2 +-
 xen/include/asm-arm/gic.h | 18 --
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2b271ba322..7938a42591 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -358,7 +358,7 @@ static void gicv2_cpu_init(void)
 /* Finest granularity of priority */
 writel_gicc(0x0, GICC_BPR);
 /* Turn on delivery */
-writel_gicc(GICC_CTL_ENABLE|GICC_CTL_EOI, GICC_CTLR);
+writel_gicc(GICC_CTL_ENABLE0|GICC_CTL_EOI, GICC_CTLR);
 }
 
 static void gicv2_cpu_disable(void)
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index b3f840ea9a..8fab458d7f 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -77,6 +77,7 @@
 #define GICC_EOIR   (0x0010)
 #define GICC_RPR(0x0014)
 #define GICC_HPPIR  (0x0018)
+#define GICC_ABPR   (0x001c)
 #define GICC_APR(0x00D0)
 #define GICC_NSAPR  (0x00E0)
 #define GICC_IIDR   (0x00FC)
@@ -102,8 +103,18 @@
 #define GICD_TYPE_SEC   0x400
 #define GICD_TYPER_DVIS (1U << 18)
 
-#define GICC_CTL_ENABLE 0x1
-#define GICC_CTL_EOI(0x1 << 9)
+#define GICC_CTL_ENABLE0_SHIFT  0
+#define GICC_CTL_ENABLE0(1U << GICC_CTL_ENABLE0_SHIFT)
+#define GICC_CTL_ENABLE1_SHIFT  1
+#define GICC_CTL_ENABLE1(1U << GICC_CTL_ENABLE1)
+#define GICC_CTL_AC_SHIFT   2
+#define GICC_CTL_AC (1U << GICC_CTL_AC_SHIFT)
+#define GICC_CTL_FIQEN_SHIFT3
+#define GICC_CTL_FIQEN  (1U << GICC_CTL_FIQEN_SHIFT)
+#define GICC_CTL_CBPR_SHIFT 4
+#define GICC_CTL_CBPR   (1U << GICC_CTL_CBPR_SHIFT)
+#define GICC_CTL_EOI_SHIFT  9
+#define GICC_CTL_EOI(1U << GICC_CTL_EOI_SHIFT)
 
 #define GICC_IA_IRQ   0x03ff
 #define GICC_IA_CPU_MASK  0x1c00
@@ -127,6 +138,9 @@
 #define GICH_MISR_VGRP1E  (1 << 6)
 #define GICH_MISR_VGRP1D  (1 << 7)
 
+#define GICV_PMR_PRIORITY_SHIFT3
+#define GICV_PMR_PRIORITY_MASK (0x1f << GICV_PMR_PRIORITY_SHIFT)
+
 /*
  * The minimum GICC_BPR is required to be in the range 0-3. We set
  * GICC_BPR to 0 but we must expect that it might be 3. This means we
-- 
2.14.1


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

[Xen-devel] [PATCH 26/57] ARM: vPL011: Use the VGIC's level triggered IRQs handling if available

[Andre Przywara]

The emulated ARM SBSA UART is using level triggered IRQ semantics,
however the current VGIC can only handle edge triggered IRQs, really.
Disable the existing workaround for this problem in case we have the
new VGIC in place, which can properly handle level triggered IRQs.

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

 xen/arch/arm/vpl011.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 5dcf4bec18..197ece8873 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -54,6 +54,7 @@ static void vpl011_update_interrupt_status(struct domain *d)
  */
 ASSERT(spin_is_locked(&vpl011->lock));
 
+#ifndef CONFIG_NEW_VGIC
 /*
  * TODO: PL011 interrupts are level triggered which means
  * that interrupt needs to be set/clear instead of being
@@ -71,6 +72,9 @@ static void vpl011_update_interrupt_status(struct domain *d)
 vgic_inject_irq(d, NULL, GUEST_VPL011_SPI, true);
 
 vpl011->shadow_uartmis = uartmis;
+#else
+vgic_inject_irq(d, NULL, GUEST_VPL011_SPI, !!uartmis);
+#endif
 }
 
 static uint8_t vpl011_read_data(struct domain *d)
-- 
2.14.1


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

[Xen-devel] [PATCH 02/57] ARM: vGICv3: clarify on GUEST_GICV3_RDIST_REGIONS symbol

[Andre Przywara]

Normally there is only one GICv3 redistributor region, and we use
that for DomU guests using a GICv3.
Explain the background in a comment and why we need to keep the number
of hardware regions for Dom0.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- Keep GUEST_GICV3_RDIST_REGIONS symbol around, just extend comments

 xen/arch/arm/vgic-v3.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 2ad8a6be62..d5b34a7d0f 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1632,6 +1632,16 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
 
 static inline unsigned int vgic_v3_rdist_count(struct domain *d)
 {
+/*
+ * Normally there is only one GICv3 redistributor region.
+ * The GICv3 DT binding provisions for multiple regions, since there are
+ * platforms out there which need those (multi-socket systems).
+ * For Dom0 we have to live with the MMIO layout the hardware provides,
+ * so we have to copy the multiple regions - as the first region may not
+ * provide enough space to hold all redistributors we need.
+ * However DomU get a constructed memory map, so we can go with
+ * the architected single redistributor region.
+ */
 return is_hardware_domain(d) ? vgic_v3_hw.nr_rdist_regions :
GUEST_GICV3_RDIST_REGIONS;
 }
@@ -1692,7 +1702,7 @@ static int vgic_v3_domain_init(struct domain *d)
 {
 d->arch.vgic.dbase = GUEST_GICV3_GICD_BASE;
 
-/* XXX: Only one Re-distributor region mapped for the guest */
+/* A single Re-distributor region is mapped for the guest. */
 BUILD_BUG_ON(GUEST_GICV3_RDIST_REGIONS != 1);
 
 d->arch.vgic.rdist_stride = GUEST_GICV3_RDIST_STRIDE;
-- 
2.14.1


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

[Xen-devel] [PATCH 43/57] ARM: new VGIC: Add SGIR register handler

[Andre Przywara]

Triggering an IPI via this register is v2 specific, so the
implementation lives entirely in vgic-mmio-v2.c.

This is based on Linux commit 55cc01fb9004, written by Andre Przywara.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- use symbolic names instead of magic values
- iterates over set bits instead of every VCPU

 xen/arch/arm/vgic/vgic-mmio-v2.c | 47 ++--
 1 file changed, 45 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 01c6a7198c..5f1fdb9a70 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -72,6 +72,49 @@ static void vgic_mmio_write_v2_misc(struct vcpu *vcpu,
 }
 }
 
+static void vgic_mmio_write_sgir(struct vcpu *source_vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+struct domain *d = source_vcpu->domain;
+unsigned int nr_vcpus = d->max_vcpus;
+unsigned int intid = val & GICD_SGI_INTID_MASK;
+unsigned long targets = (val & GICD_SGI_TARGET_MASK) >>
+GICD_SGI_TARGET_SHIFT;
+unsigned int vcpu_id;
+
+switch ( val & GICD_SGI_TARGET_LIST_MASK )
+{
+case GICD_SGI_TARGET_LIST:/* as specified by targets */
+targets &= GENMASK(nr_vcpus, 0);  /* limit to existing VCPUs */
+break;
+case GICD_SGI_TARGET_OTHERS:
+targets = GENMASK(nr_vcpus, 0);   /* all, ...   */
+targets &= ~(1U << source_vcpu->vcpu_id); /*   but self */
+break;
+case GICD_SGI_TARGET_SELF:/* this very vCPU only */
+targets = (1U << source_vcpu->vcpu_id);
+break;
+case 0x3: /* reserved */
+return;
+}
+
+for_each_set_bit( vcpu_id, &targets, 8 )
+{
+struct vcpu *vcpu = d->vcpu[vcpu_id];
+struct vgic_irq *irq = vgic_get_irq(d, vcpu, intid);
+unsigned long flags;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+irq->pending_latch = true;
+irq->source |= 1U << source_vcpu->vcpu_id;
+
+vgic_queue_irq_unlock(d, irq, flags);
+vgic_put_irq(d, irq);
+}
+}
+
 static unsigned long vgic_mmio_read_target(struct vcpu *vcpu,
paddr_t addr, unsigned int len)
 {
@@ -128,7 +171,7 @@ static void vgic_mmio_write_target(struct vcpu *vcpu,
 spin_unlock_irqrestore(&irq->irq_lock, flags);
 
 if ( desc )
-vgic_update_hardware_irq(desc, irq);
+vgic_sync_hardware_irq(vcpu->domain, desc, irq);
 
 vgic_put_irq(vcpu->domain, irq);
 }
@@ -169,7 +212,7 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_config, vgic_mmio_write_config, 2,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_LENGTH(GICD_SGIR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
+vgic_mmio_read_raz, vgic_mmio_write_sgir, 4,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_LENGTH(GICD_CPENDSGIR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
-- 
2.14.1


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

[Xen-devel] [PATCH 52/57] ARM: new VGIC: vgic-init: register VGIC

[Andre Przywara]

This patch implements the function which is called by Xen when it wants
to register the virtual GIC.
This also implements domain_max_vcpus() for the new VGIC, which reports
back the maximum number of VCPUs a certain GIC model supports.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- split off definition of domain_max_vcpus()

 xen/arch/arm/vgic/vgic-init.c | 60 +++
 xen/arch/arm/vgic/vgic.c  | 22 
 xen/arch/arm/vgic/vgic.h  |  3 +++
 3 files changed, 85 insertions(+)
 create mode 100644 xen/arch/arm/vgic/vgic-init.c

diff --git a/xen/arch/arm/vgic/vgic-init.c b/xen/arch/arm/vgic/vgic-init.c
new file mode 100644
index 00..d091c92ed0
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic-init.c
@@ -0,0 +1,60 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+
+#include "vgic.h"
+
+/* CREATION */
+
+/**
+ * domain_vgic_register: create a virtual GIC
+ * @d: domain pointer
+ * @mmio_count: pointer to add number of required MMIO regions
+ *
+ * was: kvm_vgic_create
+ */
+int domain_vgic_register(struct domain *d, int *mmio_count)
+{
+switch ( d->arch.vgic.version )
+{
+case GIC_V2:
+*mmio_count = 1;
+break;
+default:
+BUG();
+}
+
+if ( d->max_vcpus > domain_max_vcpus(d) )
+return -E2BIG;
+
+d->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
+d->arch.vgic.vgic_cpu_base = VGIC_ADDR_UNDEF;
+d->arch.vgic.vgic_redist_base = VGIC_ADDR_UNDEF;
+
+return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 5d84a4d81a..f42092fec3 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -956,6 +956,28 @@ void vgic_sync_hardware_irq(struct domain *d,
 spin_unlock_irqrestore(&desc->lock, flags);
 }
 
+unsigned int domain_max_vcpus(const struct domain *d)
+{
+unsigned int vgic_vcpu_limit;
+
+switch ( d->arch.vgic.version )
+{
+#ifdef CONFIG_HAS_GICV3
+case GIC_V3:
+vgic_vcpu_limit = VGIC_V3_MAX_CPUS;
+break;
+#endif
+case GIC_V2:
+vgic_vcpu_limit = VGIC_V2_MAX_CPUS;
+break;
+default:
+vgic_vcpu_limit = MAX_VIRT_CPUS;
+break;
+}
+
+return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index b294b04391..f19dc9502f 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -20,6 +20,9 @@
 #define PRODUCT_ID_XEN  0x58/* ASCII code X */
 #define IMPLEMENTER_ARM 0x43b
 
+#define VGIC_ADDR_UNDEF INVALID_PADDR
+#define IS_VGIC_ADDR_UNDEF(_x)  ((_x) == VGIC_ADDR_UNDEF)
+
 #define VGIC_PRI_BITS   5
 
 #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
-- 
2.14.1


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

[Xen-devel] [PATCH 37/57] ARM: new VGIC: Add ENABLE registers handlers

[Andre Przywara]

As the enable register handlers are shared between the v2 and v3
emulation, their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
This introduces a vgic_sync_hardware_irq() function, which updates the
physical side of a hardware mapped virtual IRQ.
Because the existing locking order between vgic_irq->irq_lock and
irq_desc->lock dictates so, we drop the irq_lock and retake them in the
proper order.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- extend and move vgic_sync_hardware_irq()
- do proper locking sequence
- skip already disabled/enabled IRQs

 xen/arch/arm/vgic/vgic-mmio-v2.c |   4 +-
 xen/arch/arm/vgic/vgic-mmio.c| 117 +++
 xen/arch/arm/vgic/vgic-mmio.h|  11 
 xen/arch/arm/vgic/vgic.c |  38 +
 xen/arch/arm/vgic/vgic.h |   3 +
 5 files changed, 171 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 2e015ed0b1..3dd983f885 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -80,10 +80,10 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_rao, vgic_mmio_write_wi, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISENABLER,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_enable, vgic_mmio_write_senable, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICENABLER,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_enable, vgic_mmio_write_cenable, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISPENDR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index 284a92d288..f8f0252eff 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -39,6 +39,123 @@ void vgic_mmio_write_wi(struct vcpu *vcpu, paddr_t addr,
 /* Ignore */
 }
 
+/*
+ * Read accesses to both GICD_ICENABLER and GICD_ISENABLER return the value
+ * of the enabled bit, so there is only one function for both here.
+ */
+unsigned long vgic_mmio_read_enable(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+uint32_t value = 0;
+unsigned int i;
+
+/* Loop over all IRQs affected by this read */
+for ( i = 0; i < len * 8; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+if ( irq->enabled )
+value |= (1U << i);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return value;
+}
+
+void vgic_mmio_write_senable(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+unsigned long flags;
+irq_desc_t *desc;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+if ( irq->enabled )/* skip already enabled IRQs */
+{
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+continue;
+}
+
+irq->enabled = true;
+if ( irq->hw )
+{
+/*
+ * The irq cannot be a PPI, we only support delivery
+ * of SPIs to guests.
+ */
+ASSERT(irq->hwintid >= VGIC_NR_PRIVATE_IRQS);
+
+desc = irq_to_desc(irq->hwintid);
+}
+else
+desc = NULL;
+
+vgic_queue_irq_unlock(vcpu->domain, irq, flags);
+
+if ( desc )
+vgic_sync_hardware_irq(vcpu->domain, desc, irq);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
+void vgic_mmio_write_cenable(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len,
+ unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq;
+unsigned long flags;
+irq_desc_t *desc;
+
+irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+if ( !irq->enabled )/* skip already disabled IRQs */
+{
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+continue;
+}
+
+irq->enabled = false;
+
+if ( irq->hw )
+{
+/*
+ * The irq cannot be a PPI, we only support delivery
+ * of SPIs to guests.
+ */
+ASSERT(irq->hwintid >= VGIC_NR_PRIVATE_IRQS);
+
+  

[Xen-devel] [PATCH 35/57] ARM: new VGIC: Add GICv2 MMIO handling framework

[Andre Przywara]

Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers
using the initializer macros provided by the VGIC MMIO framework.
Provide a function to register the GICv2 distributor registers to
the Xen MMIO framework.
The actual handler functions are still stubs in this patch.

This is based on Linux commit fb848db39661, written by Andre Przywara.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- drop (dummy) user interface entries
- use frame number instead of physical address

 xen/arch/arm/vgic/vgic-mmio-v2.c | 83 
 xen/arch/arm/vgic/vgic-mmio.c| 25 
 xen/arch/arm/vgic/vgic-mmio.h|  2 +
 xen/arch/arm/vgic/vgic.h |  2 +
 4 files changed, 112 insertions(+)
 create mode 100644 xen/arch/arm/vgic/vgic-mmio-v2.c

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
new file mode 100644
index 00..6f10cf16ca
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -0,0 +1,83 @@
+/*
+ * VGICv2 MMIO handling functions
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "vgic.h"
+#include "vgic-mmio.h"
+
+static const struct vgic_register_region vgic_v2_dist_registers[] = {
+REGISTER_DESC_WITH_LENGTH(GICD_CTLR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 12,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IGROUPR,
+vgic_mmio_read_rao, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISENABLER,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICENABLER,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISPENDR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICPENDR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISACTIVER,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICACTIVER,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IPRIORITYR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
+VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ITARGETSR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
+VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
+REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICFGR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 2,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_LENGTH(GICD_SGIR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
+VGIC_ACCESS_32bit),
+REGISTER_DESC_WITH_LENGTH(GICD_CPENDSGIR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
+VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
+REGISTER_DESC_WITH_LENGTH(GICD_SPENDSGIR,
+vgic_mmio_read_raz, vgic_mmio_write_wi, 16,
+VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
+};
+
+unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev)
+{
+dev->regions = vgic_v2_dist_registers;
+dev->nr_regions = ARRAY_SIZE(vgic_v2_dist_registers);
+
+return SZ_4K;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index 393460d25a..284a92d288 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -170,6 +170,31 @@ struct mmio_handler_ops vgic_io_ops = {
 .write = dispatch_mmio_write,
 };
 
+int vgic_register_dist_iodev(struct domain *d, gfn_t dist_base_fn,
+ enum vgic_type type)
+{
+struct vgic_io_device *io_device = &d->arch.vgic.dist_iodev;
+unsigned int len;
+
+switch ( type )
+{
+case VGIC_V2:
+len = vgic_v2_init_dist_iodev(io_device);
+break;
+default:
+BUG();
+}
+
+io_device->base_fn = dist_base_fn;
+io_device->iodev_type = IODEV_DIST;
+io_device->redist_vcpu = NULL;
+
+register_mmio_handler(d, &vgic_io_ops, gfn_to_gaddr(dist_base_fn), len,
+  io_device);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic/vgic-mmio.h b/xen/arch/arm/vgic/vgic-mmio.h
index 9219

[Xen-devel] [PATCH 38/57] ARM: new VGIC: Add PENDING registers handlers

[Andre Przywara]

The pending register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
For level triggered interrupts the real line level is unaffected by
this write, so we keep this state separate and combine it with the
device's level to get the actual pending state.
Hardware mapped IRQs need some special handling, as their hardware state
has to be coordinated with the virtual pending bit to avoid hanging
or masked interrupts.

This is based on Linux commit 96b298000db4, written by Andre Przywara.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- propagate SET/CLEAR_PENDING requests to hardware

 xen/arch/arm/vgic/vgic-mmio-v2.c |   4 +-
 xen/arch/arm/vgic/vgic-mmio.c| 125 +++
 xen/arch/arm/vgic/vgic-mmio.h|  11 
 3 files changed, 138 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 3dd983f885..efdd73301d 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -86,10 +86,10 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_enable, vgic_mmio_write_cenable, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISPENDR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_pending, vgic_mmio_write_spending, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICPENDR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
+vgic_mmio_read_pending, vgic_mmio_write_cpending, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ISACTIVER,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index f8f0252eff..2e939d5e39 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -156,6 +156,131 @@ void vgic_mmio_write_cenable(struct vcpu *vcpu,
 }
 }
 
+unsigned long vgic_mmio_read_pending(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+uint32_t value = 0;
+unsigned int i;
+
+/* Loop over all IRQs affected by this read */
+for ( i = 0; i < len * 8; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+if ( irq_is_pending(irq) )
+value |= (1U << i);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return value;
+}
+
+void vgic_mmio_write_spending(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len,
+  unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+unsigned long flags;
+irq_desc_t *desc;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+irq->pending_latch = true;
+
+/* To observe the locking order, just take the irq_desc pointer here. 
*/
+if ( irq->hw )
+desc = irq_to_desc(irq->hwintid);
+else
+desc = NULL;
+
+vgic_queue_irq_unlock(vcpu->domain, irq, flags);
+
+/*
+ * When the VM sets the pending state for a HW interrupt on the virtual
+ * distributor we set the active state on the physical distributor,
+ * because the virtual interrupt can become active and then the guest
+ * can deactivate it.
+ */
+if ( desc )
+{
+spin_lock_irqsave(&desc->lock, flags);
+spin_lock(&irq->irq_lock);
+
+/* Is this h/w IRQ still assigned to the virtual IRQ? */
+if ( irq->hw && desc->irq == irq->hwintid )
+gic_set_active_state(desc, true);
+
+spin_unlock(&irq->irq_lock);
+spin_unlock_irqrestore(&desc->lock, flags);
+}
+
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
+void vgic_mmio_write_cpending(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len,
+  unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 1);
+unsigned int i;
+unsigned long flags;
+irq_desc_t *desc;
+
+for_each_set_bit( i, &val, len * 8 )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+irq->pending_latch = false;
+
+/* To observe the locking order, just take the irq_desc pointer here. 
*/
+if ( irq->hw )
+desc = irq_to_desc(irq->hwintid);
+else
+desc = NULL;
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+
+/*
+ * We don't want the guest to effectively mask the physical
+ * inte

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

[Andre Przywara]

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

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- Use GIC hardware values consistently in this function.

 xen/arch/arm/gic-v3.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

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


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

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

[Andre Przywara]

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

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

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

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 5e767927c0..5d84a4d81a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -790,6 +790,14 @@ void gic_dump_vgic_info(struct vcpu *v)
 spin_unlock_irqrestore(&v->arch.vgic.ap_list_lock, flags);
 }
 
+void vgic_clear_pending_irqs(struct vcpu *v)
+{
+/*
+ * TODO: It is unclear whether we really need this, so we might instead
+ * remove it on the caller site.
+ */
+}
+
 /**
  * arch_move_irqs() - migrate the physical affinity of hardware mapped vIRQs
  * @v:  the vCPU, already assigned to the new pCPU
-- 
2.14.1


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

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

[Andre Przywara]

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

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

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

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 0bf257c865..e9ef992e1e 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -721,6 +721,50 @@ bool vgic_evtchn_irq_pending(struct vcpu *v)
 return pending;
 }
 
+bool vgic_reserve_virq(struct domain *d, unsigned int virq)
+{
+if ( virq >= vgic_num_irqs(d) )
+return false;
+
+return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
+}
+
+int vgic_allocate_virq(struct domain *d, bool spi)
+{
+int first, end;
+unsigned int virq;
+
+if ( !spi )
+{
+/* We only allocate PPIs. SGIs are all reserved */
+first = 16;
+end = 32;
+}
+else
+{
+first = 32;
+end = vgic_num_irqs(d);
+}
+
+/*
+ * There is no spinlock to protect allocated_irqs, therefore
+ * test_and_set_bit may fail. If so retry it.
+ */
+do
+{
+virq = find_next_zero_bit(d->arch.vgic.allocated_irqs, end, first);
+if ( virq >= end )
+return -1;
+} while ( test_and_set_bit(virq, d->arch.vgic.allocated_irqs) );
+
+return virq;
+}
+
+void vgic_free_virq(struct domain *d, unsigned int virq)
+{
+clear_bit(virq, d->arch.vgic.allocated_irqs);
+}
+
 struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
   unsigned int virq)
 {
-- 
2.14.1


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

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

[Andre Przywara]

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

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

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

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


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

[Xen-devel] [PATCH 57/57] ARM: VGIC: wire new VGIC(-v2) files into Xen build system

[Andre Przywara]

Now that we have both the old VGIC prepared to cope with a sibling and
the code for the new VGIC in place, lets add a Kconfig option to enable
the new code and wire it into the Xen build system.
This will add a compile time option to use either the "old" or the "new"
VGIC.
In the moment this is restricted to a vGIC-v2. To make the build system
happy, we provide a temporary dummy implementation of
vgic_v3_setup_hw() to allow building for now.

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

 xen/arch/arm/Kconfig |  6 +-
 xen/arch/arm/Makefile| 10 +-
 xen/arch/arm/vgic/vgic.c |  8 
 xen/common/Makefile  |  1 +
 4 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2782ee6589..aad19927ce 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -48,7 +48,11 @@ config HAS_GICV3
 config HAS_ITS
 bool
 prompt "GICv3 ITS MSI controller support" if EXPERT = "y"
-depends on HAS_GICV3
+depends on HAS_GICV3 && !NEW_VGIC
+
+config NEW_VGIC
+bool
+prompt "Use new VGIC implementation"
 
 config SBSA_VUART_CONSOLE
bool "Emulated SBSA UART console support"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 41d7366527..2a3ec94a18 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -16,7 +16,6 @@ obj-y += domain_build.o
 obj-y += domctl.o
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += gic.o
-obj-y += gic-vgic.o
 obj-y += gic-v2.o
 obj-$(CONFIG_HAS_GICV3) += gic-v3.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
@@ -47,10 +46,19 @@ obj-y += sysctl.o
 obj-y += time.o
 obj-y += traps.o
 obj-y += vcpreg.o
+ifeq ($(CONFIG_NEW_VGIC),y)
+obj-y += vgic/vgic.o
+obj-y += vgic/vgic-v2.o
+obj-y += vgic/vgic-mmio.o
+obj-y += vgic/vgic-mmio-v2.o
+obj-y += vgic/vgic-init.o
+else
+obj-y += gic-vgic.o
 obj-y += vgic.o
 obj-y += vgic-v2.o
 obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
+endif
 obj-y += vm_event.o
 obj-y += vtimer.o
 obj-$(CONFIG_SBSA_VUART_CONSOLE) += vpl011.o
diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index f42092fec3..f7b4779a71 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -978,6 +978,14 @@ unsigned int domain_max_vcpus(const struct domain *d)
 return min_t(unsigned int, MAX_VIRT_CPUS, vgic_vcpu_limit);
 }
 
+void vgic_v3_setup_hw(paddr_t dbase,
+  unsigned int nr_rdist_regions,
+  const struct rdist_region *regions,
+  unsigned int intid_bits)
+{
+/* Dummy implementation to allow building without actual vGICv3 support. */
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 3a349f478b..92a1d1fa58 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -19,6 +19,7 @@ obj-y += keyhandler.o
 obj-$(CONFIG_KEXEC) += kexec.o
 obj-$(CONFIG_KEXEC) += kimage.o
 obj-y += lib.o
+obj-$(CONFIG_NEW_VGIC) += list_sort.o
 obj-$(CONFIG_LIVEPATCH) += livepatch.o livepatch_elf.o
 obj-y += lzo.o
 obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o
-- 
2.14.1


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

[Xen-devel] [PATCH 32/57] ARM: new VGIC: Add GICv2 world switch backend

[Andre Przywara]

Processing maintenance interrupts and accessing the list registers
are dependent on the host's GIC version.
Introduce vgic-v2.c to contain GICv2 specific functions.
Implement the GICv2 specific code for syncing the emulation state
into the VGIC registers.
This also adds the hook to let Xen setup the host GIC addresses.

This is based on Linux commit 140b086dd197, written by Marc Zyngier.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- extend comments
- adapt to former changes
- use existing Xen LR accessor interface (->write_lr, ->read_lr)
- merge save_state and restore_state into callers
- add vgic_irq_is_mapped_level() helper

 xen/arch/arm/vgic/vgic-v2.c | 231 
 xen/arch/arm/vgic/vgic.c|   7 ++
 xen/arch/arm/vgic/vgic.h|   9 ++
 3 files changed, 247 insertions(+)
 create mode 100644 xen/arch/arm/vgic/vgic-v2.c

diff --git a/xen/arch/arm/vgic/vgic-v2.c b/xen/arch/arm/vgic/vgic-v2.c
new file mode 100644
index 00..4e74ebf7f5
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic-v2.c
@@ -0,0 +1,231 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vgic.h"
+
+static struct {
+bool enabled;
+paddr_t dbase;  /* Distributor interface address */
+paddr_t cbase;  /* CPU interface address & size */
+paddr_t csize;
+paddr_t vbase;  /* Virtual CPU interface address */
+
+/* Offset to add to get an 8kB contiguous region if GIC is aliased */
+uint32_t aliased_offset;
+} gic_v2_hw_data;
+
+void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,
+  paddr_t vbase, uint32_t aliased_offset)
+{
+gic_v2_hw_data.enabled = true;
+gic_v2_hw_data.dbase = dbase;
+gic_v2_hw_data.cbase = cbase;
+gic_v2_hw_data.csize = csize;
+gic_v2_hw_data.vbase = vbase;
+gic_v2_hw_data.aliased_offset = aliased_offset;
+}
+
+void vgic_v2_set_underflow(struct vcpu *vcpu)
+{
+gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
+}
+
+/*
+ * transfer the content of the LRs back into the corresponding ap_list:
+ * - active bit is transferred as is
+ * - pending bit is
+ *   - transferred as is in case of edge sensitive IRQs
+ *   - set to the line-level (resample time) for level sensitive IRQs
+ */
+void vgic_v2_fold_lr_state(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+unsigned int used_lrs = vcpu->arch.vgic.used_lrs;
+unsigned long flags;
+unsigned int lr;
+
+if ( !used_lrs )/* No LRs used, so nothing to sync back here. */
+return;
+
+gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 0);
+
+for ( lr = 0; lr < used_lrs; lr++ )
+{
+struct gic_lr lr_val;
+uint32_t intid;
+struct vgic_irq *irq;
+
+gic_hw_ops->read_lr(lr, &lr_val);
+
+/*
+ * TODO: Possible optimization to avoid reading LRs:
+ * Read the ELRSR to find out which of our LRs have been cleared
+ * by the guest. We just need to know the IRQ number for those, which
+ * we could save in an array when populating the LRs.
+ * This trades one MMIO access (ELRSR) for possibly more than one 
(LRs),
+ * but requires some more code to save the IRQ number and to handle
+ * those finished IRQs according to the algorithm below.
+ * We need some numbers to justify this: chances are that we don't
+ * have many LRs in use most of the time, so we might not save much.
+ */
+gic_hw_ops->clear_lr(lr);
+
+intid = lr_val.virq;
+irq = vgic_get_irq(vcpu->domain, vcpu, intid);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+/* Always preserve the active bit */
+irq->active = !!(lr_val.state & GICH_LR_ACTIVE);
+
+/* Edge is the only case where we preserve the pending bit */
+if ( irq->config == VGIC_CONFIG_EDGE && (lr_val.state & 
GICH_LR_PENDING) )
+{
+irq->pending_latch = true;
+
+if ( vgic_irq_is_sgi(intid) )
+irq->source |= (1U << lr_val.source);
+}
+
+   /*
+* Level-triggered mapped IRQs are special because we only
+* observe rising edges as input to the VGIC.
+*
+* If the guest never 

[Xen-devel] [PATCH 33/57] ARM: new VGIC: Implement vgic_vcpu_pending_irq

[Andre Przywara]

Tell Xen whether a particular VCPU has an IRQ that needs handling
in the guest. This is used to decide whether a VCPU is runnable or
if a hypercall should be preempted to let the guest handle the IRQ.

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- extend commit message
- use new function name

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

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 85e39f6f42..66a366176a 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -646,6 +646,43 @@ void vgic_sync_to_lrs(void)
 gic_hw_ops->update_hcr_status(GICH_HCR_EN, 1);
 }
 
+static int vgic_vcpu_pending_irq(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+struct vgic_irq *irq;
+bool pending = false;
+unsigned long flags;
+
+if ( !vcpu->domain->arch.vgic.enabled )
+return false;
+
+spin_lock_irqsave(&vgic_cpu->ap_list_lock, flags);
+
+list_for_each_entry(irq, &vgic_cpu->ap_list_head, ap_list)
+{
+spin_lock(&irq->irq_lock);
+pending = irq_is_pending(irq) && irq->enabled;
+spin_unlock(&irq->irq_lock);
+
+if ( pending )
+break;
+}
+
+spin_unlock_irqrestore(&vgic_cpu->ap_list_lock, flags);
+
+return pending;
+}
+
+/**
+ * vgic_pending_irq() - determine if interrupts need to be injected
+ *
+ * Returns: 1 if the guest should run to handle interrupts, 0 otherwise.
+ */
+int vgic_pending_irq(void)
+{
+return vgic_vcpu_pending_irq(current);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.14.1


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

[Xen-devel] [PATCH 17/57] ARM: Introduce kick_vcpu()

[Andre Przywara]

If we change something in a vCPU that affects its runnability or
otherwise needs the vCPU's attention, we might need to tell the scheduler
about it.
We are using this in one place (vIRQ injection) at the moment, but will
need this at more places soon.
So let's factor out this functionality in the new kick_vcpu() function
and make this available to the whole Xen arch code.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- new patch

 xen/arch/arm/smp.c| 14 ++
 xen/arch/arm/vgic.c   | 10 ++
 xen/include/asm-arm/smp.h |  3 +++
 3 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
index 62f57f0ba2..381a4786a2 100644
--- a/xen/arch/arm/smp.c
+++ b/xen/arch/arm/smp.c
@@ -4,6 +4,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 void flush_tlb_mask(const cpumask_t *mask)
 {
@@ -32,6 +34,18 @@ void smp_send_call_function_mask(const cpumask_t *mask)
 }
 }
 
+void kick_vcpu(struct vcpu *vcpu)
+{
+bool running = vcpu->is_running;
+
+vcpu_unblock(vcpu);
+if ( running && vcpu != current )
+{
+perfc_incr(vgic_cross_cpu_intr_inject);
+smp_send_event_check_mask(cpumask_of(vcpu->processor));
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 3c77d5fef6..e44de9ea95 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -530,7 +530,6 @@ int vgic_inject_irq(struct domain *d, struct vcpu *v, 
unsigned int virq,
 uint8_t priority;
 struct pending_irq *iter, *n;
 unsigned long flags;
-bool running;
 
 /*
  * For edge triggered interrupts we always ignore a "falling edge".
@@ -590,14 +589,9 @@ int vgic_inject_irq(struct domain *d, struct vcpu *v, 
unsigned int virq,
 list_add_tail(&n->inflight, &v->arch.vgic.inflight_irqs);
 out:
 spin_unlock_irqrestore(&v->arch.vgic.lock, flags);
+
 /* we have a new higher priority irq, inject it into the guest */
-running = v->is_running;
-vcpu_unblock(v);
-if ( running && v != current )
-{
-perfc_incr(vgic_cross_cpu_intr_inject);
-smp_send_event_check_mask(cpumask_of(v->processor));
-}
+kick_vcpu(v);
 
 return 0;
 }
diff --git a/xen/include/asm-arm/smp.h b/xen/include/asm-arm/smp.h
index 3c122681d7..7c8ef75789 100644
--- a/xen/include/asm-arm/smp.h
+++ b/xen/include/asm-arm/smp.h
@@ -28,6 +28,9 @@ extern void init_secondary(void);
 extern void smp_init_cpus(void);
 extern void smp_clear_cpu_maps (void);
 extern int smp_get_max_cpus (void);
+
+void kick_vcpu(struct vcpu *vcpu);
+
 #endif
 
 /*
-- 
2.14.1


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

[Xen-devel] [PATCH 14/57] ARM: VGIC: Introduce gic_get_nr_lrs()

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- move gic_get_nr_lrs() into gic.h (as a static inline)

 xen/arch/arm/gic-vgic.c   | 10 +-
 xen/include/asm-arm/gic.h |  6 ++
 2 files changed, 11 insertions(+), 5 deletions(-)

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


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

[Xen-devel] [PATCH 42/57] ARM: new VGIC: Add TARGET registers handlers

[Andre Przywara]

The target register handlers are v2 emulation specific, so their
implementation lives entirely in vgic-mmio-v2.c.
We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
set in the target mask instead of making it possibly pending on
multiple VCPUs.
We update the physical affinity of a hardware mapped vIRQ on the way.

This is based on Linux commit 2c234d6f1826, written by Andre Przywara.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- propagate affinity changes to hardware mapped IRQs

 xen/arch/arm/vgic/vgic-mmio-v2.c | 64 +++-
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index d19ddd3f1e..01c6a7198c 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -72,6 +72,68 @@ static void vgic_mmio_write_v2_misc(struct vcpu *vcpu,
 }
 }
 
+static unsigned long vgic_mmio_read_target(struct vcpu *vcpu,
+   paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+uint32_t val = 0;
+unsigned int i;
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+val |= (uint32_t)irq->targets << (i * 8);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return val;
+}
+
+static void vgic_mmio_write_target(struct vcpu *vcpu,
+   paddr_t addr, unsigned int len,
+   unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+uint8_t cpu_mask = GENMASK(vcpu->domain->max_vcpus - 1, 0);
+unsigned int i;
+unsigned long flags;
+
+/* GICD_ITARGETSR[0-7] are read-only */
+if ( intid < VGIC_NR_PRIVATE_IRQS )
+return;
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, NULL, intid + i);
+struct irq_desc *desc;
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+irq->targets = (val >> (i * 8)) & cpu_mask;
+if ( irq->targets )
+{
+irq->target_vcpu = vcpu->domain->vcpu[ffs(irq->targets) - 1];
+if ( irq->hw )
+desc = irq_to_desc(irq->hwintid);
+else
+desc = NULL;
+}
+else {
+irq->target_vcpu = NULL;
+desc = NULL;
+}
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+
+if ( desc )
+vgic_update_hardware_irq(desc, irq);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
 static const struct vgic_register_region vgic_v2_dist_registers[] = {
 REGISTER_DESC_WITH_LENGTH(GICD_CTLR,
 vgic_mmio_read_v2_misc, vgic_mmio_write_v2_misc, 12,
@@ -101,7 +163,7 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_priority, vgic_mmio_write_priority, 8,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ITARGETSR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
+vgic_mmio_read_target, vgic_mmio_write_target, 8,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICFGR,
 vgic_mmio_read_config, vgic_mmio_write_config, 2,
-- 
2.14.1


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

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

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- new patch
 xen/arch/arm/gic-v2.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

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


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

[Xen-devel] [PATCH 10/57] ARM: VGIC: rename gic_event_needs_delivery()

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- new patch

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

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index c0fe38fd37..60c6c463e9 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -339,7 +339,7 @@ void gic_clear_pending_irqs(struct vcpu *v)
 gic_remove_from_lr_pending(v, p);
 }
 
-int gic_events_need_delivery(void)
+int vgic_pending_irq(void)
 {
 struct vcpu *v = current;
 struct pending_irq *p;
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index e8c2a6cb44..c4c79fa87d 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -24,7 +24,7 @@ static inline int local_events_need_delivery_nomask(void)
  * interrupts disabled so this shouldn't be a problem in the general
  * case.
  */
-if ( gic_events_need_delivery() )
+if ( vgic_pending_irq() )
 return 1;
 
 if ( !vcpu_info(current, evtchn_upcall_pending) )
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 3b2d0217a6..a23c307c3a 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -238,7 +238,7 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned 
int virq,
 
 extern void vgic_sync_to_lrs(void);
 extern void gic_clear_pending_irqs(struct vcpu *v);
-extern int gic_events_need_delivery(void);
+extern int vgic_pending_irq(void);
 
 extern void init_maintenance_interrupt(void);
 extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
-- 
2.14.1


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

[Xen-devel] [PATCH 19/57] ARM: GICv3: poke_irq: make RWP optional

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- new patch

 xen/arch/arm/gic-v3.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

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


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

[Xen-devel] [PATCH 21/57] ARM: GICv2: extend LR read/write functions to cover EOI and source

[Andre Przywara]

So far our LR read/write functions do not handle the EOI bit and the
source CPUID bits in an LR, because the current VGIC implementation does
not use them.
Extend the gic_lr data structure to hold these bits of information as
well, packing it on the way to avoid it to grow.
Then extract and assemble those bits from/to an LR.

This allows the new VGIC to use this information.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- new patch

 xen/arch/arm/gic-v2.c | 7 +++
 xen/include/asm-arm/gic.h | 8 +---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 031be920cc..c5ec0d4d35 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -470,6 +470,9 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
 lr_reg->state = (lrv >> GICH_V2_LR_STATE_SHIFT) & 
GICH_V2_LR_STATE_MASK;
 lr_reg->hw_status = (lrv >> GICH_V2_LR_HW_SHIFT) & GICH_V2_LR_HW_MASK;
 lr_reg->grp   = (lrv >> GICH_V2_LR_GRP_SHIFT) & GICH_V2_LR_GRP_MASK;
+lr_reg->eoi   = !!(lrv & GICH_V2_LR_MAINTENANCE_IRQ);
+if ( lr_reg->virq < NR_GIC_SGI )
+lr_reg->source = (lrv >> GICH_V2_LR_CPUID_SHIFT) & 
GICH_V2_LR_CPUID_MASK;
 }
 
 static void gicv2_write_lr(int lr, const struct gic_lr *lr_reg)
@@ -485,6 +488,10 @@ static void gicv2_write_lr(int lr, const struct gic_lr 
*lr_reg)
   ((uint32_t)(lr_reg->hw_status & GICH_V2_LR_HW_MASK)
<< GICH_V2_LR_HW_SHIFT)  |
   ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << 
GICH_V2_LR_GRP_SHIFT) );
+if ( lr_reg->eoi )
+lrv |= GICH_V2_LR_MAINTENANCE_IRQ;
+if ( lr_reg->virq < NR_GIC_SGI )
+lrv |= (uint32_t)lr_reg->source << GICH_V2_LR_CPUID_SHIFT;
 
 writel_gich(lrv, GICH_LR + lr * 4);
 }
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 8fab458d7f..89a07ae6b4 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -223,9 +223,11 @@ struct gic_lr {
/* Virtual IRQ */
uint32_t virq;
uint8_t priority;
-   uint8_t state;
-   uint8_t hw_status;
-   uint8_t grp;
+   uint8_t source;
+   uint8_t state:2;
+   uint8_t hw_status:1;
+   uint8_t grp:1;
+   uint8_t eoi:1;
 };
 
 enum gic_version {
-- 
2.14.1


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

[Xen-devel] [PATCH 40/57] ARM: new VGIC: Add PRIORITY registers handlers

[Andre Przywara]

The priority register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
There is a corner case when we change the priority of a pending
interrupt which we don't handle at the moment.

This is based on Linux commit dd238ec2b87b, written by Andre Przywara.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- use 32 bit register types

 xen/arch/arm/vgic/vgic-mmio-v2.c |  2 +-
 xen/arch/arm/vgic/vgic-mmio.c| 47 
 xen/arch/arm/vgic/vgic-mmio.h|  7 ++
 xen/arch/arm/vgic/vgic.h |  2 ++
 4 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index c93455fbb2..29db9dec6f 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -98,7 +98,7 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_active, vgic_mmio_write_cactive, 1,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_IPRIORITYR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
+vgic_mmio_read_priority, vgic_mmio_write_priority, 8,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ITARGETSR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index c44d67082f..538f08bc66 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -384,6 +384,53 @@ void vgic_mmio_write_sactive(struct vcpu *vcpu,
 }
 }
 
+unsigned long vgic_mmio_read_priority(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+unsigned int i;
+uint32_t val = 0;
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+val |= (uint32_t)irq->priority << (i * 8);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return val;
+}
+
+/*
+ * We currently don't handle changing the priority of an interrupt that
+ * is already pending on a VCPU. If there is a need for this, we would
+ * need to make this VCPU exit and re-evaluate the priorities, potentially
+ * leading to this interrupt getting presented now to the guest (if it has
+ * been masked by the priority mask before).
+ */
+void vgic_mmio_write_priority(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len,
+  unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 8);
+unsigned int i;
+unsigned long flags;
+
+for ( i = 0; i < len; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+spin_lock_irqsave(&irq->irq_lock, flags);
+/* Narrow the priority range to what we actually support */
+irq->priority = (val >> (i * 8)) & GENMASK(7, 8 - VGIC_PRI_BITS);
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
 static int match_region(const void *key, const void *elt)
 {
 const unsigned int offset = (unsigned long)key;
diff --git a/xen/arch/arm/vgic/vgic-mmio.h b/xen/arch/arm/vgic/vgic-mmio.h
index 8604720628..e3f9029344 100644
--- a/xen/arch/arm/vgic/vgic-mmio.h
+++ b/xen/arch/arm/vgic/vgic-mmio.h
@@ -129,6 +129,13 @@ void vgic_mmio_write_sactive(struct vcpu *vcpu,
  paddr_t addr, unsigned int len,
  unsigned long val);
 
+unsigned long vgic_mmio_read_priority(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len);
+
+void vgic_mmio_write_priority(struct vcpu *vcpu,
+  paddr_t addr, unsigned int len,
+  unsigned long val);
+
 unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
 
 #endif
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
index 68e205d10a..b294b04391 100644
--- a/xen/arch/arm/vgic/vgic.h
+++ b/xen/arch/arm/vgic/vgic.h
@@ -20,6 +20,8 @@
 #define PRODUCT_ID_XEN  0x58/* ASCII code X */
 #define IMPLEMENTER_ARM 0x43b
 
+#define VGIC_PRI_BITS   5
+
 #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
 
 static inline bool irq_is_pending(struct vgic_irq *irq)
-- 
2.14.1


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

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

[Andre Przywara]

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

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

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

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

[Xen-devel] [PATCH 06/57] ARM: vGICv3: remove rdist_stride from VGIC structure

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
Changelog RFC ... v1:
- Add Julien's ACK

 xen/arch/arm/gic-v3.c |  3 +--
 xen/arch/arm/vgic-v3.c| 14 --
 xen/include/asm-arm/domain.h  |  1 -
 xen/include/asm-arm/vgic.h|  1 -
 xen/include/public/arch-arm.h |  1 -
 5 files changed, 1 insertion(+), 19 deletions(-)

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


___
Xen-devel mailing list

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

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- new patch

 xen/arch/arm/gic-v3.c | 48 +++---
 xen/include/asm-arm/gic_v3_defs.h | 49 +++
 2 files changed, 48 insertions(+), 49 deletions(-)

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

[Xen-devel] [PATCH 30/57] ARM: new VGIC: Add IRQ sorting

[Andre Przywara]

Adds the sorting function to cover the case where you have more IRQs
to consider than you have LRs. We consider their priorities.
This pulls in Linux' list_sort.c, which is a merge sort implementation
for linked lists. Apart from adding a full featured license header and
adjusting the #include file, nothing has been changed in this code.

This is based on Linux commit 8e4447457965, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- use Linux coding style for list_sort.c

 xen/arch/arm/vgic/vgic.c|  59 +
 xen/common/list_sort.c  | 157 
 xen/include/xen/list_sort.h |  11 
 3 files changed, 227 insertions(+)
 create mode 100644 xen/common/list_sort.c
 create mode 100644 xen/include/xen/list_sort.h

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index ae922815bd..efa6c67cb7 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "vgic.h"
@@ -182,6 +183,64 @@ static struct vcpu *vgic_target_oracle(struct vgic_irq 
*irq)
 return NULL;
 }
 
+/*
+ * The order of items in the ap_lists defines how we'll pack things in LRs as
+ * well, the first items in the list being the first things populated in the
+ * LRs.
+ *
+ * A hard rule is that active interrupts can never be pushed out of the LRs
+ * (and therefore take priority) since we cannot reliably trap on deactivation
+ * of IRQs and therefore they have to be present in the LRs.
+ *
+ * Otherwise things should be sorted by the priority field and the GIC
+ * hardware support will take care of preemption of priority groups etc.
+ *
+ * Return negative if "a" sorts before "b", 0 to preserve order, and positive
+ * to sort "b" before "a".
+ */
+static int vgic_irq_cmp(void *priv, struct list_head *a, struct list_head *b)
+{
+struct vgic_irq *irqa = container_of(a, struct vgic_irq, ap_list);
+struct vgic_irq *irqb = container_of(b, struct vgic_irq, ap_list);
+bool penda, pendb;
+int ret;
+
+spin_lock(&irqa->irq_lock);
+spin_lock(&irqb->irq_lock);
+
+if ( irqa->active || irqb->active )
+{
+ret = (int)irqb->active - (int)irqa->active;
+goto out;
+}
+
+penda = irqa->enabled && irq_is_pending(irqa);
+pendb = irqb->enabled && irq_is_pending(irqb);
+
+if ( !penda || !pendb )
+{
+ret = (int)pendb - (int)penda;
+goto out;
+}
+
+/* Both pending and enabled, sort by priority */
+ret = irqa->priority - irqb->priority;
+out:
+spin_unlock(&irqb->irq_lock);
+spin_unlock(&irqa->irq_lock);
+return ret;
+}
+
+/* Must be called with the ap_list_lock held */
+static void vgic_sort_ap_list(struct vcpu *vcpu)
+{
+struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic;
+
+ASSERT(spin_is_locked(&vgic_cpu->ap_list_lock));
+
+list_sort(NULL, &vgic_cpu->ap_list_head, vgic_irq_cmp);
+}
+
 /*
  * Only valid injection if changing level for level-triggered IRQs or for a
  * rising edge.
diff --git a/xen/common/list_sort.c b/xen/common/list_sort.c
new file mode 100644
index 00..af2b2f6519
--- /dev/null
+++ b/xen/common/list_sort.c
@@ -0,0 +1,157 @@
+/*
+ * list_sort.c: merge sort implementation for linked lists
+ * Copied from the Linux kernel (lib/list_sort.c)
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
+
+#include 
+#include 
+
+#define MAX_LIST_LENGTH_BITS 20
+
+/*
+ * Returns a list organized in an intermediate format suited
+ * to chaining of merge() calls: null-terminated, no reserved or
+ * sentinel head node, "prev" links not maintained.
+ */
+static struct list_head *merge(void *priv,
+   int (*cmp)(void *priv, struct list_head *a,
+   struct list_head *b),
+   struct list_head *a, struct list_head *b)
+{
+   struct list_head head, *tail = &head;
+
+   while (a && b) {
+   /* if equal, take 'a' -- important for sort stability */
+   if ((*cmp)(priv, a, b) <= 0) {
+   tail->next = a;
+   a = a->next;
+   } else {
+   tail->next = b;
+   b = b->next;
+   }
+   tail = tail->next;
+   }
+   tail->next = a?:b;
+   return head.next;
+}
+
+/*
+ * Combine final li

[Xen-devel] [PATCH 34/57] ARM: new VGIC: Add MMIO handling framework

[Andre Przywara]

Add an MMIO handling framework to the VGIC emulation:
Each register is described by its offset, size (or number of bits per
IRQ, if applicable) and the read/write handler functions. We provide
initialization macros to describe each GIC register later easily.

Separate dispatch functions for read and write accesses are connected
to Xen's MMIO handling framework and binary-search for the responsible
register handler based on the offset address within the region.

The register handler prototype are courtesy of Christoffer Dall.

This is based on Linux commit 4493b1c4866a, written by Marc Zyngier.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- adapt to former changes
- whitespace fixes
- use C99 data types
- drop unneeded regions support (ITS, CPU i/f)

 xen/arch/arm/vgic/vgic-mmio.c | 180 ++
 xen/arch/arm/vgic/vgic-mmio.h |  99 +++
 2 files changed, 279 insertions(+)
 create mode 100644 xen/arch/arm/vgic/vgic-mmio.c
 create mode 100644 xen/arch/arm/vgic/vgic-mmio.h

diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
new file mode 100644
index 00..393460d25a
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -0,0 +1,180 @@
+/*
+ * VGIC MMIO handling functions
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vgic.h"
+#include "vgic-mmio.h"
+
+unsigned long vgic_mmio_read_raz(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len)
+{
+return 0;
+}
+
+unsigned long vgic_mmio_read_rao(struct vcpu *vcpu,
+ paddr_t addr, unsigned int len)
+{
+return -1UL;
+}
+
+void vgic_mmio_write_wi(struct vcpu *vcpu, paddr_t addr,
+unsigned int len, unsigned long val)
+{
+/* Ignore */
+}
+
+static int match_region(const void *key, const void *elt)
+{
+const unsigned int offset = (unsigned long)key;
+const struct vgic_register_region *region = elt;
+
+if ( offset < region->reg_offset )
+return -1;
+
+if ( offset >= region->reg_offset + region->len )
+return 1;
+
+return 0;
+}
+
+static const struct vgic_register_region *
+vgic_find_mmio_region(const struct vgic_register_region *regions,
+  int nr_regions, unsigned int offset)
+{
+return bsearch((void *)(uintptr_t)offset, regions, nr_regions,
+   sizeof(regions[0]), match_region);
+}
+
+static bool check_region(const struct domain *d,
+ const struct vgic_register_region *region,
+ paddr_t addr, int len)
+{
+int flags, nr_irqs = d->arch.vgic.nr_spis + VGIC_NR_PRIVATE_IRQS;
+
+switch ( len )
+{
+case sizeof(uint8_t):
+flags = VGIC_ACCESS_8bit;
+break;
+case sizeof(uint32_t):
+flags = VGIC_ACCESS_32bit;
+break;
+case sizeof(uint64_t):
+flags = VGIC_ACCESS_64bit;
+break;
+default:
+return false;
+}
+
+if ( (region->access_flags & flags) && IS_ALIGNED(addr, len) )
+{
+if ( !region->bits_per_irq )
+return true;
+
+/* Do we access a non-allocated IRQ? */
+return VGIC_ADDR_TO_INTID(addr, region->bits_per_irq) < nr_irqs;
+}
+
+return false;
+}
+
+static const struct vgic_register_region *
+vgic_get_mmio_region(struct vcpu *vcpu, struct vgic_io_device *iodev,
+ paddr_t addr, unsigned int len)
+{
+const struct vgic_register_region *region;
+
+region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
+   addr - gfn_to_gaddr(iodev->base_fn));
+if ( !region || !check_region(vcpu->domain, region, addr, len) )
+return NULL;
+
+return region;
+}
+
+static int dispatch_mmio_read(struct vcpu *vcpu, mmio_info_t *info,
+  register_t *r, void *priv)
+{
+struct vgic_io_device *iodev = priv;
+const struct vgic_register_region *region;
+unsigned long data = 0;
+paddr_t addr = info->gpa;
+int len = 1U << info->dabt.size;
+
+region = vgic_get_mmio_region(vcpu, iodev, addr, len);
+if ( !region )
+{
+memset(r, 0, len);
+return 0;
+}
+
+switch (iodev->iodev_type)
+{
+case IODEV_DIST:
+data = region->read(vcpu, addr, len);
+break;
+case IODEV_REDIST:
+data = region->read(iodev->redist_vcpu, addr, len);
+break;
+ 

[Xen-devel] [PATCH 41/57] ARM: new VGIC: Add CONFIG registers handlers

[Andre Przywara]

The config register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.

This is based on Linux commit 79717e4ac09c, written by Andre Przywara.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- use C99 data types

 xen/arch/arm/vgic/vgic-mmio-v2.c |  2 +-
 xen/arch/arm/vgic/vgic-mmio.c| 54 
 xen/arch/arm/vgic/vgic-mmio.h|  7 ++
 3 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic/vgic-mmio-v2.c b/xen/arch/arm/vgic/vgic-mmio-v2.c
index 29db9dec6f..d19ddd3f1e 100644
--- a/xen/arch/arm/vgic/vgic-mmio-v2.c
+++ b/xen/arch/arm/vgic/vgic-mmio-v2.c
@@ -104,7 +104,7 @@ static const struct vgic_register_region 
vgic_v2_dist_registers[] = {
 vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
 VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
 REGISTER_DESC_WITH_BITS_PER_IRQ(GICD_ICFGR,
-vgic_mmio_read_raz, vgic_mmio_write_wi, 2,
+vgic_mmio_read_config, vgic_mmio_write_config, 2,
 VGIC_ACCESS_32bit),
 REGISTER_DESC_WITH_LENGTH(GICD_SGIR,
 vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
diff --git a/xen/arch/arm/vgic/vgic-mmio.c b/xen/arch/arm/vgic/vgic-mmio.c
index 538f08bc66..31f7cf706b 100644
--- a/xen/arch/arm/vgic/vgic-mmio.c
+++ b/xen/arch/arm/vgic/vgic-mmio.c
@@ -431,6 +431,60 @@ void vgic_mmio_write_priority(struct vcpu *vcpu,
 }
 }
 
+unsigned long vgic_mmio_read_config(struct vcpu *vcpu,
+paddr_t addr, unsigned int len)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 2);
+uint32_t value = 0;
+int i;
+
+for ( i = 0; i < len * 4; i++ )
+{
+struct vgic_irq *irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+
+if ( irq->config == VGIC_CONFIG_EDGE )
+value |= (2U << (i * 2));
+
+vgic_put_irq(vcpu->domain, irq);
+}
+
+return value;
+}
+
+void vgic_mmio_write_config(struct vcpu *vcpu,
+paddr_t addr, unsigned int len,
+unsigned long val)
+{
+uint32_t intid = VGIC_ADDR_TO_INTID(addr, 2);
+int i;
+unsigned long flags;
+
+for ( i = 0; i < len * 4; i++ )
+{
+struct vgic_irq *irq;
+
+/*
+ * The configuration cannot be changed for SGIs in general,
+ * for PPIs this is IMPLEMENTATION DEFINED. The arch timer
+ * code relies on PPIs being level triggered, so we also
+ * make them read-only here.
+ */
+if ( intid + i < VGIC_NR_PRIVATE_IRQS )
+continue;
+
+irq = vgic_get_irq(vcpu->domain, vcpu, intid + i);
+spin_lock_irqsave(&irq->irq_lock, flags);
+
+if ( test_bit(i * 2 + 1, &val) )
+irq->config = VGIC_CONFIG_EDGE;
+else
+irq->config = VGIC_CONFIG_LEVEL;
+
+spin_unlock_irqrestore(&irq->irq_lock, flags);
+vgic_put_irq(vcpu->domain, irq);
+}
+}
+
 static int match_region(const void *key, const void *elt)
 {
 const unsigned int offset = (unsigned long)key;
diff --git a/xen/arch/arm/vgic/vgic-mmio.h b/xen/arch/arm/vgic/vgic-mmio.h
index e3f9029344..bbf0d181ae 100644
--- a/xen/arch/arm/vgic/vgic-mmio.h
+++ b/xen/arch/arm/vgic/vgic-mmio.h
@@ -136,6 +136,13 @@ void vgic_mmio_write_priority(struct vcpu *vcpu,
   paddr_t addr, unsigned int len,
   unsigned long val);
 
+unsigned long vgic_mmio_read_config(struct vcpu *vcpu,
+paddr_t addr, unsigned int len);
+
+void vgic_mmio_write_config(struct vcpu *vcpu,
+paddr_t addr, unsigned int len,
+unsigned long val);
+
 unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
 
 #endif
-- 
2.14.1


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

[Xen-devel] [PATCH 18/57] ARM: GICv2: introduce gicv2_poke_irq()

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- new patch

 xen/arch/arm/gic-v2.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

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


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

[Xen-devel] [PATCH 22/57] ARM: GIC: Allow tweaking the active and pending state of an IRQ

[Andre Przywara]

When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active or pending state of an
interrupt at some point.
To prepare the GIC for that, we introduce a set_active_state() and a
set_pending_state() function to let the VGIC manipulate the state of
an associated hardware IRQ.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- use struct irq_desc* in the interface (instead of just the IRQ number)
- add set_pending_state() (needed later)

 xen/arch/arm/gic-v2.c | 32 
 xen/arch/arm/gic-v3.c | 28 
 xen/arch/arm/gic.c| 10 ++
 xen/include/asm-arm/gic.h | 10 ++
 4 files changed, 80 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index c5ec0d4d35..74169b5633 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -241,6 +241,36 @@ static void gicv2_poke_irq(struct irq_desc *irqd, uint32_t 
offset)
 writel_gicd(1U << (irqd->irq % 32), offset + (irqd->irq / 32) * 4);
 }
 
+static void gicv2_set_active_state(struct irq_desc *irqd, bool active)
+{
+ASSERT(spin_is_locked(&irqd->lock));
+
+if ( active )
+{
+set_bit(_IRQ_INPROGRESS, &irqd->status);
+gicv2_poke_irq(irqd, GICD_ISACTIVER);
+}
+else
+{
+gicv2_poke_irq(irqd, GICD_ICACTIVER);
+}
+}
+
+static void gicv2_set_pending_state(struct irq_desc *irqd, bool pending)
+{
+ASSERT(spin_is_locked(&irqd->lock));
+
+if ( pending )
+{
+set_bit(_IRQ_INPROGRESS, &irqd->status);
+gicv2_poke_irq(irqd, GICD_ISPENDR);
+}
+else
+{
+gicv2_poke_irq(irqd, GICD_ICPENDR);
+}
+}
+
 static void gicv2_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
 uint32_t cfg, actual, edgebit;
@@ -1251,6 +1281,8 @@ const static struct gic_hw_operations gicv2_ops = {
 .eoi_irq = gicv2_eoi_irq,
 .deactivate_irq  = gicv2_dir_irq,
 .read_irq= gicv2_read_irq,
+.set_active_state= gicv2_set_active_state,
+.set_pending_state   = gicv2_set_pending_state,
 .set_irq_type= gicv2_set_irq_type,
 .set_irq_priority= gicv2_set_irq_priority,
 .send_SGI= gicv2_send_SGI,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 44dfba2267..c96469f09d 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -477,6 +477,32 @@ static unsigned int gicv3_read_irq(void)
 return irq;
 }
 
+static void gicv3_set_active_state(struct irq_desc *irqd, bool active)
+{
+ASSERT(spin_is_locked(&irqd->lock));
+
+if ( active )
+{
+set_bit(_IRQ_INPROGRESS, &irqd->status);
+gicv3_poke_irq(irqd, GICD_ISACTIVER, false);
+}
+else
+gicv3_poke_irq(irqd, GICD_ICACTIVER, false);
+}
+
+static void gicv3_set_pending_state(struct irq_desc *irqd, bool pending)
+{
+ASSERT(spin_is_locked(&irqd->lock));
+
+if ( pending )
+{
+set_bit(_IRQ_INPROGRESS, &irqd->status);
+gicv3_poke_irq(irqd, GICD_ISPENDR, false);
+}
+else
+gicv3_poke_irq(irqd, GICD_ICPENDR, false);
+}
+
 static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
 {
  uint64_t mpidr = cpu_logical_map(cpu);
@@ -1723,6 +1749,8 @@ static const struct gic_hw_operations gicv3_ops = {
 .eoi_irq = gicv3_eoi_irq,
 .deactivate_irq  = gicv3_dir_irq,
 .read_irq= gicv3_read_irq,
+.set_active_state= gicv3_set_active_state,
+.set_pending_state   = gicv3_set_pending_state,
 .set_irq_type= gicv3_set_irq_type,
 .set_irq_priority= gicv3_set_irq_priority,
 .send_SGI= gicv3_send_sgi,
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 968e46fabb..f1329a630a 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -87,6 +87,16 @@ void gic_restore_state(struct vcpu *v)
 isb();
 }
 
+void gic_set_active_state(struct irq_desc *irqd, bool state)
+{
+gic_hw_ops->set_active_state(irqd, state);
+}
+
+void gic_set_pending_state(struct irq_desc *irqd, bool state)
+{
+gic_hw_ops->set_pending_state(irqd, state);
+}
+
 /* desc->irq needs to be disabled before calling this function */
 void gic_set_irq_type(struct irq_desc *desc, unsigned int type)
 {
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 89a07ae6b4..46dcb0fe7c 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -239,6 +239,12 @@ DECLARE_PER_CPU(uint64_t, lr_mask);
 
 extern enum gic_version gic_hw_version(void);
 
+/* Force the active state of an IRQ. */
+void gic_set_active_state(struct irq_desc *irqd, bool state);
+
+/* Force the pending state of an IRQ. */
+void gic_set_pending_state(struct irq_desc *irqd, bool state);
+
 /* Program the IRQ type into the GIC */
 void gic_set_irq_type(struct irq_desc *desc, unsigned int type);
 
@@ -348,6 +354,10 @@ struct gic_hw_operations {
 void (*deactivate_irq)(struct ir

[Xen-devel] [PATCH 01/57] tools: ARM: vGICv3: Avoid inserting optional DT properties

[Andre Przywara]

When creating a GICv3 devicetree node, we currently insert the
redistributor-stride and #redistributor-regions properties, with fixed
values which are actually the architected ones. Since those properties are
optional, and in the case of the stride only needed to cover for broken
platforms, we don't need to describe them if they don't differ from the
default values. This will always be the case for our constructed
DomU memory map.
So we drop those properties altogether and provide a clean and architected
GICv3 DT node for DomUs.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- improve commit message

 tools/libxl/libxl_arm.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 86f59c0d80..906fd0dcdf 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -525,14 +525,6 @@ static int make_gicv3_node(libxl__gc *gc, void *fdt)
 res = fdt_property(fdt, "interrupt-controller", NULL, 0);
 if (res) return res;
 
-res = fdt_property_cell(fdt, "redistributor-stride",
-GUEST_GICV3_RDIST_STRIDE);
-if (res) return res;
-
-res = fdt_property_cell(fdt, "#redistributor-regions",
-GUEST_GICV3_RDIST_REGIONS);
-if (res) return res;
-
 res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
 2,
 gicd_base, gicd_size,
-- 
2.14.1


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

[Xen-devel] [PATCH 12/57] ARM: VGIC: carve out struct vgic_cpu and struct vgic_dist

[Andre Przywara]

Currently we describe the VGIC specific fields in a structure
*embedded* in struct arch_domain and struct arch_vcpu. These members
there are however related to the current VGIC implementation, and will
be substantially different in the future.
To allow coexistence of two implementations, move the definition of these
embedded structures into vgic.h, and just use the opaque type in the arch
specific structures.
This allows easy switching between different implementations later.

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

 xen/include/asm-arm/domain.h | 85 +-
 xen/include/asm-arm/vgic.h   | 88 
 2 files changed, 90 insertions(+), 83 deletions(-)

diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 1dd9683d25..bb7a46c1d0 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -74,57 +74,7 @@ struct arch_domain
 uint64_t offset;
 } virt_timer_base;
 
-struct {
-/* Version of the vGIC */
-enum gic_version version;
-/* GIC HW version specific vGIC driver handler */
-const struct vgic_ops *handler;
-/*
- * Covers access to other members of this struct _except_ for
- * shared_irqs where each member contains its own locking.
- *
- * If both class of lock is required then this lock must be
- * taken first. If multiple rank locks are required (including
- * the per-vcpu private_irqs rank) then they must be taken in
- * rank order.
- */
-spinlock_t lock;
-uint32_t ctlr;
-int nr_spis; /* Number of SPIs */
-unsigned long *allocated_irqs; /* bitmap of IRQs allocated */
-struct vgic_irq_rank *shared_irqs;
-/*
- * SPIs are domain global, SGIs and PPIs are per-VCPU and stored in
- * struct arch_vcpu.
- */
-struct pending_irq *pending_irqs;
-/* Base address for guest GIC */
-paddr_t dbase; /* Distributor base address */
-#ifdef CONFIG_HAS_GICV3
-/* GIC V3 addressing */
-/* List of contiguous occupied by the redistributors */
-struct vgic_rdist_region {
-paddr_t base;   /* Base address */
-paddr_t size;   /* Size */
-unsigned int first_cpu; /* First CPU handled */
-} *rdist_regions;
-int nr_regions; /* Number of rdist regions */
-unsigned long int nr_lpis;
-uint64_t rdist_propbase;
-struct rb_root its_devices; /* Devices mapped to an ITS */
-spinlock_t its_devices_lock;/* Protects the its_devices tree */
-struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
-rwlock_t pend_lpi_tree_lock;/* Protects the pend_lpi_tree */
-struct list_head vits_list; /* List of virtual ITSes */
-unsigned int intid_bits;
-/*
- * TODO: if there are more bool's being added below, consider
- * a flags variable instead.
- */
-bool rdists_enabled;/* Is any redistributor enabled? */
-bool has_its;
-#endif
-} vgic;
+struct vgic_dist vgic;
 
 struct vuart {
 #define VUART_BUF_SIZE 128
@@ -247,38 +197,7 @@ struct arch_vcpu
 union gic_state_data gic;
 uint64_t lr_mask;
 
-struct {
-/*
- * SGIs and PPIs are per-VCPU, SPIs are domain global and in
- * struct arch_domain.
- */
-struct pending_irq pending_irqs[32];
-struct vgic_irq_rank *private_irqs;
-
-/* This list is ordered by IRQ priority and it is used to keep
- * track of the IRQs that the VGIC injected into the guest.
- * Depending on the availability of LR registers, the IRQs might
- * actually be in an LR, and therefore injected into the guest,
- * or queued in gic.lr_pending.
- * As soon as an IRQ is EOI'd by the guest and removed from the
- * corresponding LR it is also removed from this list. */
-struct list_head inflight_irqs;
-/* lr_pending is used to queue IRQs (struct pending_irq) that the
- * vgic tried to inject in the guest (calling gic_set_guest_irq) but
- * no LRs were available at the time.
- * As soon as an LR is freed we remove the first IRQ from this
- * list and write it to the LR register.
- * lr_pending is a subset of vgic.inflight_irqs. */
-struct list_head lr_pending;
-spinlock_t lock;
-
-/* GICv3: redistributor base and flags for this vCPU */
-paddr_t rdist_base;
-uint64_t rdist_pendbase;
-#define VGIC_V3_RDIST_LAST  (1 << 0)/* last vCPU of the rdist */
-#define VGIC_V3_LPIS_ENABLED(1 << 1)
-uint8_t flags;
-} vgic;
+struct vgic_cpu vgic;
 
 /* T

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

[Andre Przywara]

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

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
Changelog RFC ... v1:
- Remove two redundant prototypes
- Add Julien's Reviewed-by:

 xen/include/asm-arm/vgic.h | 54 +-
 1 file changed, 30 insertions(+), 24 deletions(-)

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

[Xen-devel] [PATCH 04/57] ARM: GICv3: simplify GICv3 redistributor stride handling

[Andre Przywara]

Instead of hard coding the architected redistributor stride into the
code, lets use a clear #define to the two values for GICv3 and GICv4 and
clarify the algorithm to determine the needed stride value.

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

 xen/arch/arm/gic-v3.c | 18 ++
 xen/include/asm-arm/gic_v3_defs.h |  5 +
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b1f8a86409..be1787b39a 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -690,6 +690,15 @@ static int __init gicv3_populate_rdist(void)
 do {
 typer = readq_relaxed(ptr + GICR_TYPER);
 
+/* Set the architectural redist size if not overridden by DT. */
+if ( !gicv3.rdist_stride )
+{
+if ( typer & GICR_TYPER_VLPIS )
+gicv3.rdist_stride = GICV4_GICR_SIZE;
+else
+gicv3.rdist_stride = GICV3_GICR_SIZE;
+}
+
 if ( (typer >> 32) == aff )
 {
 this_cpu(rbase) = ptr;
@@ -732,14 +741,7 @@ static int __init gicv3_populate_rdist(void)
 if ( gicv3.rdist_regions[i].single_rdist )
 break;
 
-if ( gicv3.rdist_stride )
-ptr += gicv3.rdist_stride;
-else
-{
-ptr += SZ_64K * 2; /* Skip RD_base + SGI_base */
-if ( typer & GICR_TYPER_VLPIS )
-ptr += SZ_64K * 2; /* Skip VLPI_base + reserved page */
-}
+ptr += gicv3.rdist_stride;
 
 } while ( !(typer & GICR_TYPER_LAST) );
 }
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 65c9dc47cf..412e41afed 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -18,6 +18,8 @@
 #ifndef __ASM_ARM_GIC_V3_DEFS_H__
 #define __ASM_ARM_GIC_V3_DEFS_H__
 
+#include 
+
 /*
  * Additional registers defined in GIC v3.
  * Common GICD registers are defined in gic.h
@@ -68,6 +70,9 @@
 #define GICV3_GICD_IIDR_VAL  0x34c
 #define GICV3_GICR_IIDR_VAL  GICV3_GICD_IIDR_VAL
 
+#define GICV3_GICR_SIZE  (2 * SZ_64K)
+#define GICV4_GICR_SIZE  (4 * SZ_64K)
+
 #define GICR_CTLR(0x)
 #define GICR_IIDR(0x0004)
 #define GICR_TYPER   (0x0008)
-- 
2.14.1


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

[Xen-devel] [PATCH 09/57] ARM: VGIC: Move domain_max_vcpus() to be VGIC specific

[Andre Przywara]

domain_max_vcpus(), which is used by generic Xen code, returns the
maximum number of VCPUs for a domain, which on ARM is mostly limited by
the VGIC model emulated (a (v)GICv2 can only handle 8 CPUs).
Our current implementation lives in arch/arm/domain.c, but reaches into
VGIC internal data structures.
Move this function into vgic.c, to keep this VGIC internal.

Signed-off-by: Andre Przywara 
---
Changelog RFC ... v1:
- dump previous approach, move function to VGIC specific file instead

 xen/arch/arm/domain.c | 14 --
 xen/arch/arm/vgic.c   | 14 ++
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index a010443bfd..8546443bad 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -968,20 +968,6 @@ void vcpu_block_unless_event_pending(struct vcpu *v)
 vcpu_unblock(current);
 }
 
-unsigned int domain_max_vcpus(const struct domain *d)
-{
-/*
- * Since evtchn_init would call domain_max_vcpus for poll_mask
- * allocation when the vgic_ops haven't been initialised yet,
- * we return MAX_VIRT_CPUS if d->arch.vgic.handler is null.
- */
-if ( !d->arch.vgic.handler )
-return MAX_VIRT_CPUS;
-else
-return min_t(unsigned int, MAX_VIRT_CPUS,
- d->arch.vgic.handler->max_vcpus);
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 34269bcf27..c3fdcebbde 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -665,6 +665,20 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
 clear_bit(virq, d->arch.vgic.allocated_irqs);
 }
 
+unsigned int domain_max_vcpus(const struct domain *d)
+{
+/*
+ * Since evtchn_init would call domain_max_vcpus for poll_mask
+ * allocation when the vgic_ops haven't been initialised yet,
+ * we return MAX_VIRT_CPUS if d->arch.vgic.handler is null.
+ */
+if ( !d->arch.vgic.handler )
+return MAX_VIRT_CPUS;
+else
+return min_t(unsigned int, MAX_VIRT_CPUS,
+ d->arch.vgic.handler->max_vcpus);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.14.1


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

[Xen-devel] [PATCH 00/57] New VGIC(-v2) implementation

[Andre Przywara]

tl;dr: Coarse changelog below, individual patches have changelogs as
well.

This is an updated version of the new VGIC-v2 implementation.
Compared to the RFC posted a month ago, many things have been changed to
address the review comments. The most important things are:
- The GICv3 redistributor cleanup patches at the beginning of this series
have been fixed to address the previous review comments.
- The "physical-follows-virtual" IRQ affinity functionality is now implemented.
- Trying to shrink data structures, namely struct vgic_irq.
- Removing not needed data structures and code stubs for parts dealing
with ITS or the CPU interface emulation.
- Renaming of some existing Xen function names to be more readable.
- Use existing LR accessor functions when updating/sycing LR content.
- Dumping extra save/restore_state functions when syncing to/from LRs.
- Fixes and adjustments to locking scheme.
- Improving ACTIVE MMIO handling, documenting limitations.
- Many minor changes to address whitespace issues, data types (uint32_t
vs. u32, unsigned vs. signed), extended comments and commit messages.

An summarising changelog can be found below, each individual patch has
its own changelog as well.

There are some things that have (still) not been covered yet:
- struct VCPU still allocates two pages now. We can either limit this to
ARM64 && the new VGIC, or try to look if we can allocate some parts of
struct vcpu instead of embedding sub-structures into it.
- vGICv3 support is not implemented, but should be fairly straight-forward to
add, as the design incorporated this already. Will look at this next.
- There is a possible DOS vector on the VCPU ap_list, which holds pending
vIRQs. A guest can make this list rather long, which forces the hypervisor
to hold the list lock when iterating the list. This should be bounded by
the number of emulated vIRQs though, and there are ideas how to mitigate
this issue. Those fixes would be posted on top as fixes later.
- There is no ITS support, though the VGIC code itself is more ready for that
than the old VGIC ever was. However due to differences between the Xen
and KVM architecture the ITS bits are not easy to port over to Xen.

Cheers,
Andre

=
During development of the Dom0 ITS MSI support last year we realised
that the existing GIC interrupt controller emulation has some shortcomings.
After some tries to fix those in the existing code, it was agreed upon
that the problems are fundamental and a new implementation based on the
"new VGIC" in KVM is the best choice.
This is the first drop of this new VGIC implementation. It lives in the
xen/arch/arm/vgic/ directory and is written to be a compile time option,
so people can choose whether to use the new VGIC or the existing
implementation. This is just for a transitional period, the old VGIC is
expected to be removed after confidence in the new implementation has grown.

This series starts with some GICv3 redistributor cleanup, which I posted
before. I need to incorporate the comments from the list, but for now I left
those patches as it from the previous post.

Starting with patch 07 there are some more cleanups and preparations for
the existing VGIC/GIC code. A big part of those patches are preparations to
properly support level triggered interrupts. This is one of the biggest
problems in the existing VGIC, which only correctly emulates edge triggered
IRQs. This affects both arch code and some users like the timer and the
event channel.

Starting with patch 27 we plumb in the new VGIC then. This is done in a
new directory, with all the files actually not wired into the build system
until the very last patch. The idea is to split the series into reviewable
chunks without resorting to nasty hacks to keep bisectability.
The code was forked from Linux' virt/kvm/arm/vgic/, as of 4.14-rc7, plus
some recent changes to improve support for level triggered and hardware
mapped interrupts, which is what we use heavily in Dom0. The code was
heavily adapted to fit into Xen, starting with using the Xen coding style
and using Xen structure and variable names (struct domain instead of
struct kvm, for instance). Where interfacing functions were similar enough,
they were changed over to the existing Xen name and prototypes (for instance
kvm_vgic_create() was renamed to domain_vgic_register()). As far as possible
the code layout and split was re-used from KVM, so patches in Linux should
be relatively easy to port into Xen. Due to the mentioned changes this can
not be done easily in an automatic way, but it should be not too complicated
to extract the gist of the patch and re-apply this to our code base.

The actual VGIC code splits into several parts:
- The core is the struct vgic_irq, which holds every information about a
virtual IRQ, including a per-IRQ lock. Also there is on (ordered) per-VCPU
list (ap_list), which links the interrupts to be considered by a VCPU.
There are functions to deal with queuing and removing IRQs from t

Re: [Xen-devel] [PATCH v4 12/20] x86emul: support SWAPGS

[Andrew Cooper]

On 28/02/18 13:06, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v4 08/20] x86emul: abstract out XCRn accesses

[Andrew Cooper]

On 28/02/18 13:03, Jan Beulich wrote:
> @@ -5178,18 +5202,33 @@ x86_emulate(
>  _regs.eflags |= X86_EFLAGS_AC;
>  break;
>  
> -#ifdef __XEN__
> -case 0xd1: /* xsetbv */
> +case 0xd0: /* xgetbv */
>  generate_exception_if(vex.pfx, EXC_UD);
> -if ( !ops->read_cr || ops->read_cr(4, &cr4, ctxt) != 
> X86EMUL_OKAY )
> +if ( !ops->read_cr || !ops->read_xcr ||
> + ops->read_cr(4, &cr4, ctxt) != X86EMUL_OKAY )
>  cr4 = 0;
>  generate_exception_if(!(cr4 & X86_CR4_OSXSAVE), EXC_UD);
> -generate_exception_if(!mode_ring0() ||
> -  handle_xsetbv(_regs.ecx,
> -_regs.eax | (_regs.rdx << 
> 32)),
> +generate_exception_if(_regs.ecx > (vcpu_has_xgetbv1() ? 1 : 0),
>EXC_GP, 0);

I'm still opposed to this change.  It is inconsistent with all other
handling in the emulator, because we do not do input register validation
for any of the CR/DR/MSR hooks.

The {read,write}_xcr() hooks should be required to deal with any
arbitrary register, just like the {read,write}_{cr,dr,msr}() hooks are
currently expected to do.

Everything else is fine (subject to the adjustments required to change
this property).

~Andrew

> +rc = ops->read_xcr(_regs.ecx, &msr_val, ctxt);
> +if ( rc != X86EMUL_OKAY )
> +goto done;
> +_regs.r(ax) = (uint32_t)msr_val;
> +_regs.r(dx) = msr_val >> 32;
> +break;
> +
> +case 0xd1: /* xsetbv */
> +generate_exception_if(vex.pfx, EXC_UD);
> +if ( !ops->read_cr || !ops->write_xcr ||
> + ops->read_cr(4, &cr4, ctxt) != X86EMUL_OKAY )
> +cr4 = 0;
> +generate_exception_if(!(cr4 & X86_CR4_OSXSAVE), EXC_UD);
> +generate_exception_if(!mode_ring0() || _regs.ecx, EXC_GP, 0);
> +rc = ops->write_xcr(_regs.ecx,
> +_regs.eax | ((uint64_t)_regs.edx << 32), 
> ctxt);
> +if ( rc != X86EMUL_OKAY )
> +goto done;
>  break;
> -#endif
>  
>  case 0xd4: /* vmfunc */
>  generate_exception_if(vex.pfx, EXC_UD);
>


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

Re: [Xen-devel] [PATCH v4 07/20] x86: move and rename XSTATE_*

[Andrew Cooper]

On 28/02/18 13:00, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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