Re: [Xen-devel] PCI Pass-through / Config Space emulation for ARM64

[Manish Jaggi]

On 07/18/2018 03:27 PM, Manish Jaggi wrote:



On 07/02/2018 07:51 PM, Roger Pau Monné wrote:

External Email

On Mon, Jul 02, 2018 at 04:16:05PM +0530, Manish Jaggi wrote:

Hi All,

PCI-PT and PCI config space emulation have been in discussion for 
quite a

long time.
We had started some work on this in past and in LEG-XEN but that 
didnt go

far and the group is closed.

I believe that PCI-PT is a feature which would be suitable for not 
only for

servers but for embedded platforms as well.

I would like know the interest in the developer community on this, 
so that

we can be
able to complete this in the time frame of 4.12 release.

I'm not involved with the ARM side, but I think targeting
ARM pci-passthrough for 4.12 might be too optimistic. AFAICT ARM
doesn't yet have any kind of pci support, so you will have to:

  - Get Xen to access the pci config space on ARM.
  - Implement trapping for pci config accesses for ARM guests.
  - Enable vpci and implement the arch specific hooks for MSI and MSI-X
    interrupt routing.
  - Audit the current vpci code and implement the missing features (and
    restrictions) so it can be used by unprivileged domains. vpci ATM
    is only used by PVH Dom0, and that's a trusted domain.

That's in my opinion quite a lot of work, and I'm not sure a lot of
this can be done concurrently. Each step depends on the previous one
being functional (except for the last one that can be implemented on
x86 right now).


ARM PCI Passthrough list of tasks
-

This small document is the follow up of the past discussions on 
mailing list

Reference to earlier documents [1] and [2].
Some of these tasks were started internals / while linaro-xen was active.

Below is the list of features to be supported in order to have device
passthrough working on xen. I have started on 1. Basic PCI support,
I am merging my code with some code julien had written.

Does this list looks ok? or If I missed something please feel free to add

1. Basic PCI support
1.1 Support in Xen
    a. pci config space read write apis'
    b. ert

typo
Read  b. ecam based hostbridge support

(Xen would be touching host bridge directly)
    c. implement PHYSDEVOP_pci_add_device hypercall
    d. implement PHYSDEVOP_pci_mmcfg_reserved
    e. Trap & Emulate PCI config space access's for Dom0
    For Dom0 the access would be just forwarded to hostbridge 
driver, no filter
    This is done just to avoid xen and Dom0 both touching config 
space.


1.2 Support in Linux
    a. Dom0 finds PCI hostbridge in ACPI tables or in device tree
    b. Dom0 registers the pci hostbridge with Xen
    b.1 this PHYSDEVOP_pci_mmcfg_reserved hypercall is required for
    agreement on seg number using config space address.

Limitation: Only PCI ECAM based hostbridges would be supported.

2. SMMU Support for Dom0 devices
    a. Generate IORT for Dom0 by hiding SMMU node
    b. Add SMMU programming in the flow of PHYSDEVOP_pci_add_device 
hypercall

    c. Map ITS MSI Doorbell space in Dom0, mapping 1:1

3. Device Assignment to DomU
3.1 libxl
    a. ACPI
    - to provide IORT for DomU for ACPI
    - add generic ecam device in MADT

    b. DTS
    - Add pci device node in guest dt for generic ecam

    c. Mapping ITS Doorbell Space in DomU
    - mapping not 1:1, this can be done through
    a hypercall from libxl at the time of domain creation.

    d. Mapping guest sbdf - host sbdf
    - so that GIC-ITS MAPD command trapping should program proper
    deviceID.
3.2 Xen
    a. Trap and Emulate PCI config space for DomU (generic ecam)
    - assigned PCI devices should be enumerated.

3.3 Linux
    will not use pci frontend backend for config space access

4. Non-ECAM compliant pci-hostbridge support
4.1 Import Drivers from Linux into Xen
   Advantages
    - Back and forth between Dom0 and xen can be avoided
    Tradeoffs
    - Porting and maintenance effort.



[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02520.html
[2] 
https://lists.xenproject.org/ardhaves/html/xen-devel/2016-12/msg00224.html

Roger.





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

Re: [Xen-devel] PCI Pass-through / Config Space emulation for ARM64

[Manish Jaggi]

On 07/02/2018 07:51 PM, Roger Pau Monné wrote:

External Email

On Mon, Jul 02, 2018 at 04:16:05PM +0530, Manish Jaggi wrote:

Hi All,

PCI-PT and PCI config space emulation have been in discussion for quite a
long time.
We had started some work on this in past and in LEG-XEN but that didnt go
far and the group is closed.

I believe that PCI-PT is a feature which would be suitable for not only for
servers but for embedded platforms as well.

I would like know the interest in the developer community on this, so that
we can be
able to complete this in the time frame of 4.12 release.

I'm not involved with the ARM side, but I think targeting
ARM pci-passthrough for 4.12 might be too optimistic. AFAICT ARM
doesn't yet have any kind of pci support, so you will have to:

  - Get Xen to access the pci config space on ARM.
  - Implement trapping for pci config accesses for ARM guests.
  - Enable vpci and implement the arch specific hooks for MSI and MSI-X
interrupt routing.
  - Audit the current vpci code and implement the missing features (and
restrictions) so it can be used by unprivileged domains. vpci ATM
is only used by PVH Dom0, and that's a trusted domain.

That's in my opinion quite a lot of work, and I'm not sure a lot of
this can be done concurrently. Each step depends on the previous one
being functional (except for the last one that can be implemented on
x86 right now).


ARM PCI Passthrough list of tasks
-

This small document is the follow up of the past discussions on mailing list
Reference to earlier documents [1] and [2].
Some of these tasks were started internals / while linaro-xen was active.

Below is the list of features to be supported in order to have device
passthrough working on xen. I have started on 1. Basic PCI support,
I am merging my code with some code julien had written.

Does this list looks ok? or If I missed something please feel free to add

1. Basic PCI support
1.1 Support in Xen
    a. pci config space read write apis'
    b. ert
    (Xen would be touching host bridge directly)
    c. implement PHYSDEVOP_pci_add_device hypercall
    d. implement PHYSDEVOP_pci_mmcfg_reserved
    e. Trap & Emulate PCI config space access's for Dom0
    For Dom0 the access would be just forwarded to hostbridge 
driver, no filter

    This is done just to avoid xen and Dom0 both touching config space.

1.2 Support in Linux
    a. Dom0 finds PCI hostbridge in ACPI tables or in device tree
    b. Dom0 registers the pci hostbridge with Xen
    b.1 this PHYSDEVOP_pci_mmcfg_reserved hypercall is required for
    agreement on seg number using config space address.

Limitation: Only PCI ECAM based hostbridges would be supported.

2. SMMU Support for Dom0 devices
    a. Generate IORT for Dom0 by hiding SMMU node
    b. Add SMMU programming in the flow of PHYSDEVOP_pci_add_device 
hypercall

    c. Map ITS MSI Doorbell space in Dom0, mapping 1:1

3. Device Assignment to DomU
3.1 libxl
    a. ACPI
    - to provide IORT for DomU for ACPI
    - add generic ecam device in MADT

    b. DTS
    - Add pci device node in guest dt for generic ecam

    c. Mapping ITS Doorbell Space in DomU
    - mapping not 1:1, this can be done through
    a hypercall from libxl at the time of domain creation.

    d. Mapping guest sbdf - host sbdf
    - so that GIC-ITS MAPD command trapping should program proper
    deviceID.
3.2 Xen
    a. Trap and Emulate PCI config space for DomU (generic ecam)
    - assigned PCI devices should be enumerated.

3.3 Linux
    will not use pci frontend backend for config space access

4. Non-ECAM compliant pci-hostbridge support
4.1 Import Drivers from Linux into Xen
   Advantages
    - Back and forth between Dom0 and xen can be avoided
    Tradeoffs
    - Porting and maintenance effort.



[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-05/msg02520.html
[2] 
https://lists.xenproject.org/ardhaves/html/xen-devel/2016-12/msg00224.html

Roger.



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

[Xen-devel] PCI Pass-through / Config Space emulation for ARM64

[Manish Jaggi]

Hi All,

PCI-PT and PCI config space emulation have been in discussion for quite 
a long time.
We had started some work on this in past and in LEG-XEN but that didnt 
go far and the group is closed.


I believe that PCI-PT is a feature which would be suitable for not only 
for servers but for embedded platforms as well.


I would like know the interest in the developer community on this, so 
that we can be

able to complete this in the time frame of 4.12 release.
My idea is that we can form a small group and split up the work as per 
interest.


-Thanks
Manish

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

Re: [Xen-devel] [v3 5/6] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Manish Jaggi]

Hi Sameer,


On 06/08/2018 05:17 AM, Sameer Goel wrote:

Pull common defines for SMMU drives in a local header.

Can add more detail in commit message?


Signed-off-by: Sameer Goel 
---
  xen/drivers/passthrough/arm/smmu-v3.c |  96 +---
  xen/drivers/passthrough/arm/smmu.c| 104 +
  xen/drivers/passthrough/arm/smmu.h| 125 ++
  3 files changed, 128 insertions(+), 197 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/smmu.h

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index 75c3411ad9..fdf85c1508 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -49,28 +49,7 @@
  #include 
  #include 
  
-/* Alias to Xen device tree helpers */

-#define device_node dt_device_node
-#define of_phandle_args dt_phandle_args
-#define of_device_id dt_device_match
-#define of_match_node dt_match_node
-#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
-#define of_property_read_bool dt_property_read_bool
-#define of_parse_phandle_with_args dt_parse_phandle_with_args
-
-/* Xen: Helpers to get device MMIO and IRQs */

Added and removed in subsequent patches? code specific to xen.
you can remove from patch#4 itself.

-struct resource {
-   u64 addr;
-   u64 size;
-   unsigned int type;
-};
-
-#define resource_size(res) ((res)->size)
-
-#define platform_device device
-
-#define IORESOURCE_MEM 0
-#define IORESOURCE_IRQ 1
+#include "smmu.h"
  
  static struct resource *platform_get_resource(struct platform_device *pdev,

  unsigned int type,
@@ -200,79 +179,6 @@ static void dmam_free_coherent(struct device *dev, size_t 
size, void *vaddr,
xfree(vaddr);
  }
  
-/* Xen: Stub out DMA domain related functions */

-#define iommu_get_dma_cookie(dom) 0
-#define iommu_put_dma_cookie(dom)
-
-/* Xen: Stub out module param related function */
-#define module_param_named(a, b, c, d)
-#define MODULE_PARM_DESC(a, b)
-
-#define dma_set_mask_and_coherent(d, b) 0
-
-#define of_dma_is_coherent(n) 0
-
-#define MODULE_DEVICE_TABLE(type, name)
-
-static void __iomem *devm_ioremap_resource(struct device *dev,
-  struct resource *res)
-{
-   void __iomem *ptr;
-
-   if (!res || res->type != IORESOURCE_MEM) {
-   dev_err(dev, "Invalid resource\n");
-   return ERR_PTR(-EINVAL);
-   }
-
-   ptr = ioremap_nocache(res->addr, res->size);
-   if (!ptr) {
-   dev_err(dev,
-   "ioremap failed (addr 0x%"PRIx64" size 0x%"PRIx64")\n",
-   res->addr, res->size);
-   return ERR_PTR(-ENOMEM);
-   }
-
-   return ptr;
-}
-
-/* Xen: Compatibility define for iommu_domain_geometry.*/
-struct iommu_domain_geometry {
-   dma_addr_t aperture_start; /* First address that can be mapped*/
-   dma_addr_t aperture_end;   /* Last address that can be mapped */
-   bool force_aperture;   /* DMA only allowed in mappable range? */
-};
-
-
-/* Xen: Type definitions for iommu_domain */
-#define IOMMU_DOMAIN_UNMANAGED 0
-#define IOMMU_DOMAIN_DMA 1
-#define IOMMU_DOMAIN_IDENTITY 2
-
-/* Xen: Dummy iommu_domain */
-struct iommu_domain {
-   /* Runtime SMMU configuration for this iommu_domain */
-   struct arm_smmu_domain  *priv;
-   unsigned int type;
-
-   /* Dummy compatibility defines */
-   unsigned long pgsize_bitmap;
-   struct iommu_domain_geometry geometry;
-
-   atomic_t ref;
-   /*
-* Used to link iommu_domain contexts for a same domain.
-* There is at least one per-SMMU to used by the domain.
-*/
-   struct list_headlist;
-};
-
This xen dummy structure was introduced in patch 4 and now removing in 
patch5,

Can you remove it from patch 4 itself?

-/* Xen: Describes information required for a Xen domain */
-struct arm_smmu_xen_domain {
-   spinlock_t  lock;
-   /* List of iommu domains associated to this domain */
-   struct list_headcontexts;
-};
-

Same as above

  /*
   * Xen: Information about each device stored in dev->archdata.iommu
   *
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index ad956d5b8d..f7a6b107de 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -41,6 +41,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -51,36 +52,13 @@
  #include 
  #include 
  
+#include "smmu.h" /* Not a self contained header. So last in the list */

  /* Xen: The below defines are redefined within the file. Undef it */
  #undef SCTLR_AFE
  #undef SCTLR_TRE
  #undef SCTLR_M
  #undef TTBCR_EAE
  
-/* Alias to Xen device tree helpers */

-#define device_node dt_device_node
-#define of_phandle_args 

Re: [Xen-devel] [PATCH v5 0/10] arm: more kconfig configurability and small default configs

[Manish Jaggi]

Hi Stefano,


On 06/04/2018 10:53 PM, Stefano Stabellini wrote:

Hi all,

This patch series is the first step toward building a small certifiable
Xen hypervisor for ARM boards.

How much code size can be reduced ? any ballpark figure


First, the series makes a few changes to allow disabling more kconfig
options: most of them already exist but cannot be disabled.

Then, it introduces a reference kconfig for Renesas RCar (due to popular
demand, candidate for certifications), Xilinx MPSoC, and for QEMU
aarch64 (not for certifications, but useful for debugging).

The last patch in the series adds a convenient cloc target to count the
total lines of code of the source files built.

As a consequence of these changes, some options will become user-visible
and not dependent on CONFIG_EXPERT. It does not mean that Xen Project
will security support all possible combinations of kconfig options.
Instead, there will be a small set of pre-canned configurations that
will be supported.  See: https://marc.info/?l=xen-devel=152424389512432

Cheers,

Stefano


Stefano Stabellini (10):
   arm: remove the ARM HDLCD driver
   arm: make it possible to disable HAS_GICV3
   arm: rename HAS_GICV3 to GICV3
   Make MEM_ACCESS configurable
   make it possible to enable/disable UART drivers
   arm: make it possible to disable the SMMU driver
   arm: add a tiny kconfig configuration
   arm: add ALL, QEMU, Rcar3 and MPSoC configs
   xen: add per-platform defaults for NR_CPUS
   xen: add cloc target

  tools/firmware/xen-dir/shim.config   |   2 +-
  xen/Makefile |  12 ++
  xen/arch/Kconfig |   4 +
  xen/arch/arm/Kconfig |  17 +-
  xen/arch/arm/Makefile|   4 +-
  xen/arch/arm/configs/tiny.conf   |  43 +
  xen/arch/arm/platforms/Kconfig   |  54 ++
  xen/arch/arm/platforms/Makefile  |   2 +-
  xen/arch/arm/platforms/vexpress.c|  35 
  xen/arch/arm/vgic.c  |   2 +-
  xen/arch/arm/vgic/vgic.c |   2 +-
  xen/arch/x86/Kconfig |   2 +-
  xen/common/Kconfig   |  10 +-
  xen/common/Makefile  |   2 +-
  xen/common/domctl.c  |   2 +-
  xen/drivers/char/Kconfig |  15 +-
  xen/drivers/passthrough/Kconfig  |  12 ++
  xen/drivers/passthrough/arm/Makefile |   2 +-
  xen/drivers/video/Kconfig|   3 -
  xen/drivers/video/Makefile   |   1 -
  xen/drivers/video/arm_hdlcd.c| 281 ---
  xen/include/asm-arm/gic.h|   4 +-
  xen/include/asm-arm/platforms/vexpress.h |   6 -
  xen/include/asm-arm/vgic.h   |   4 +-
  xen/include/xen/mem_access.h |   4 +-
  xen/include/xsm/dummy.h  |   2 +-
  xen/include/xsm/xsm.h|   4 +-
  xen/xsm/dummy.c  |   2 +-
  xen/xsm/flask/hooks.c|   4 +-
  29 files changed, 175 insertions(+), 362 deletions(-)
  create mode 100644 xen/arch/arm/configs/tiny.conf
  create mode 100644 xen/arch/arm/platforms/Kconfig
  delete mode 100644 xen/drivers/video/arm_hdlcd.c

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



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

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

On 06/02/2018 12:28 AM, Sameer Goel wrote:


On 5/31/2018 11:16 PM, Manish Jaggi wrote:


On 05/31/2018 09:27 PM, Sameer Goel wrote:

On 5/30/2018 10:13 PM, Manish Jaggi wrote:

On 05/31/2018 04:31 AM, Sameer Goel wrote:

+
+static int arm_smmu_iommu_domain_init(struct domain *d)

Where is iommu_domain initialized?
The function does not use a iommu_domain * variable

Please check iommu.c 2 levels up.

In this function do you see iommu_domain getting allocated or initialized?
As per the name of function arm_smmu iommu_domain_init.
Where is init of iommu_domain in this function?

Well without the xen_domain the iommu_domain is not initialized. It is just the 
default value. This generic iommu code makes an .init call to our code for 
whatever initialization is needed. So the name here seemed absolutely fine to 
me.

Initialization does not always refer to allocation. In this case this is driver 
specific initialization. Since, the iommu code is making an init call to the 
smmu code hence the name arm_smmu_iommu_domain_init. So, again I agree with 
your comments on the domain variable names and I'm making these changes as they 
would make the code cleaner. This function name change probably will not do 
much but the move along the discussion, let me know what you were thinking.

Sameer, few points
a. all the functions are prefixed with arm_smmu_ , so what the function is 
doing can be understood by the rest part of the name
In this case it is iommu_domain_init.

b. By the name it seems to suggest that you are  doing some kind of init for 
iommu_domain

c. But in this complete function, iommu_domain pointer is never used.

If I take your point, the appropriate name of the function should be 
arm_smmu_xen_domain_init().

Its not the iommu domain defined within the current driver.  I'll change the 
name to arm_smmu_xen_iommu_init().

arm_smmu for just keeping the prefixes as needed. Sounds good?

yes. thanks.


Thanks,
Sameer

-Manish

+static int arm_smmu_iommu_domain_init(struct domain *d)
+{
+    struct arm_smmu_xen_domain *xen_domain;
+
+    xen_domain = xzalloc(struct arm_smmu_xen_domain);
+    if (!xen_domain)
+    return -ENOMEM;
+
+    spin_lock_init(_domain->lock);
+    INIT_LIST_HEAD(_domain->contexts);
+
+    dom_iommu(d)->arch.priv = xen_domain;
+
+    return 0;
+}
+




Thanks,
Sameer

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

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


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


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



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

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

On 05/31/2018 09:27 PM, Sameer Goel wrote:


On 5/30/2018 10:13 PM, Manish Jaggi wrote:


On 05/31/2018 04:31 AM, Sameer Goel wrote:

+
+static int arm_smmu_iommu_domain_init(struct domain *d)

Where is iommu_domain initialized?
The function does not use a iommu_domain * variable

Please check iommu.c 2 levels up.

In this function do you see iommu_domain getting allocated or initialized?
As per the name of function arm_smmu iommu_domain_init.
Where is init of iommu_domain in this function?

Well without the xen_domain the iommu_domain is not initialized. It is just the 
default value. This generic iommu code makes an .init call to our code for 
whatever initialization is needed. So the name here seemed absolutely fine to 
me.

Initialization does not always refer to allocation. In this case this is driver 
specific initialization. Since, the iommu code is making an init call to the 
smmu code hence the name arm_smmu_iommu_domain_init. So, again I agree with 
your comments on the domain variable names and I'm making these changes as they 
would make the code cleaner. This function name change probably will not do 
much but the move along the discussion, let me know what you were thinking.

Sameer, few points
a. all the functions are prefixed with arm_smmu_ , so what the function 
is doing can be understood by the rest part of the name

In this case it is iommu_domain_init.

b. By the name it seems to suggest that you are  doing some kind of init 
for iommu_domain


c. But in this complete function, iommu_domain pointer is never used.

If I take your point, the appropriate name of the function should be 
arm_smmu_xen_domain_init().


-Manish

+static int arm_smmu_iommu_domain_init(struct domain *d)
+{
+    struct arm_smmu_xen_domain *xen_domain;
+
+    xen_domain = xzalloc(struct arm_smmu_xen_domain);
+    if (!xen_domain)
+    return -ENOMEM;
+
+    spin_lock_init(_domain->lock);
+    INIT_LIST_HEAD(_domain->contexts);
+
+    dom_iommu(d)->arch.priv = xen_domain;
+
+    return 0;
+}
+




Thanks,
Sameer

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


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



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

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

On 05/31/2018 04:31 AM, Sameer Goel wrote:

+
+static int arm_smmu_iommu_domain_init(struct domain *d)

Where is iommu_domain initialized?
The function does not use a iommu_domain * variable

Please check iommu.c 2 levels up.

In this function do you see iommu_domain getting allocated or initialized?
As per the name of function arm_smmu iommu_domain_init.
Where is init of iommu_domain in this function?

+static int arm_smmu_iommu_domain_init(struct domain *d)
+{
+   struct arm_smmu_xen_domain *xen_domain;
+
+   xen_domain = xzalloc(struct arm_smmu_xen_domain);
+   if (!xen_domain)
+   return -ENOMEM;
+
+   spin_lock_init(_domain->lock);
+   INIT_LIST_HEAD(_domain->contexts);
+
+   dom_iommu(d)->arch.priv = xen_domain;
+
+   return 0;
+}
+




Thanks,
Sameer


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



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

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

On 05/31/2018 01:16 AM, Sameer Goel wrote:

Manish, I'll take another look at the variable names. I might not have enough 
time :).


On 05/23/2018 10:48 PM, Manish Jaggi wrote:

Hi Sameer,

General Comment, please use appropriate variable names for XXX_domain 
structures in code which is xen specific.

I thought that we had discussed this before on one of the RFCs.

Yes and no one replied to my last comment that the var names have to be non 
confusing in Xen specific code.

I'm sorry about that. I just assumed that since the policy on ported variable 
names was consistent we so not nee to change the names.


At this point we are just using the format used for smmu-v2.

smmu-v2 has a lot of confusing variable names with _domain.
I believe that file needs to be fixed as well.

I don't think that the variable names are inappropriate. Unless there is a very 
specific issue with the variable names,

The issue is in code readability and understanding the flow.
It is confusing so many _domain variable names are used which are not verbose.

These names are coming from the original Linux code. So, we do not change them 
as per the policy. That being said I can add a comment section to explain the 
confusing variables in the Xen specific code? Please let me know if this will 
help us resolve this issue?
  
If it is in Xen specific functions, then it can be changed, this is what 
julien also confirmed.



Two functions different and confusing variable names

+static int __must_check arm_smmu_iotlb_flush_all(struct domain *d)
+{
+    struct arm_smmu_xen_domain *smmu_domain;

+static struct iommu_domain *arm_smmu_get_domain(struct domain *d,
+    struct device *dev)
+{
+    struct iommu_domain *domain;
+    struct arm_smmu_xen_domain *xen_domain;

Why use smmu_domain at one place and xen_domain at another ?
Intuitively xen_domain should mean a VM.

Doesn't is look confusing?

Please take a look, I have pointed out the other specific ones below.

I think we should stick with the current version.



On 05/24/2018 06:16 AM, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- xen/linux_compat: Add a Linux compat header
    For porting files directly from Linux it is useful to have a function 
mapping
    definitions from Linux to Xen. This file adds common API functions and
    other defines that are needed for porting arm SMMU drivers.

Signed-off-by: Sameer Goel 
---
   xen/arch/arm/p2m.c    |   1 +
   xen/drivers/Kconfig   |   2 +
   xen/drivers/passthrough/arm/Kconfig   |   8 +
   xen/drivers/passthrough/arm/Makefile  |   1 +
   xen/drivers/passthrough/arm/smmu-v3.c | 934 +-
   xen/include/xen/linux_compat.h    |  84 +++
   6 files changed, 1001 insertions(+), 29 deletions(-)
   create mode 100644 xen/drivers/passthrough/arm/Kconfig
   create mode 100644 xen/include/xen/linux_compat.h

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..38aa9f00c1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1454,6 +1454,7 @@ err:
   static void __init setup_virt_paging_one(void *data)
   {
   unsigned long val = (unsigned long)data;
+    /* SMMUv3 S2 cfg vtcr reuses the following value */
   WRITE_SYSREG32(val, VTCR_EL2);
   isb();
   }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index db94393f47..59ca00f850 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -15,4 +15,6 @@ source "drivers/video/Kconfig"
   config HAS_VPCI
   bool
   +source "drivers/passthrough/arm/Kconfig"
+
   endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+    bool "ARM SMMUv3 Support"
+    depends on ARM_64
+    help
+ Support for implementations of the ARM System MMU architecture
+ version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
   obj-y += iommu.o
   obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..df81626785 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,414 @@
    * Author: Will Deacon 
    *
    * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4

[Xen-devel] [PATCH v3 17/17] arm64: if trapping a read-from-write-only GICv3 access inject undef exception in guest

[Manish Jaggi]

This patch is ported to xen from linux commit:
e7f1d1eef482150a64a6e6ad8faf40f8f97eed67
KVM: arm64: Log an error if trapping a read-from-write-only GICv3 access

A read-from-write-only GICv3 access should UNDEF at EL1. But since
we're in complete paranoia-land with broken CPUs, let's assume the
worse and gracefully handle the case.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index ac39eb5e1d..1b36b104bc 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -792,6 +792,11 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 
 case HSR_SYSREG_ICC_EOIR0_EL1:
 case HSR_SYSREG_ICC_EOIR1_EL1:
+if ( unlikely(is_read) )
+{
+ret = false;
+goto end;
+}
 fn = vgic_v3_write_eoir;
 break;
 
-- 
2.14.1


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

[Xen-devel] [PATCH v3 15/17] arm: Hook workaround handler from traps.c based on Cavium workaround_30115

[Manish Jaggi]

From: Manish Jaggi <manish.ja...@cavium.com>

Function vgic_v3_handle_cpuif_access is called from do_trap_guest_sync
if ARM64_WORKAROUND_CAVIUM_30115 capability is found.

A flag skip_hyp_tail is introduced in struct cpu_info. This flag
is used to skip leave_hypervisor_tail when enter_hypervisor_head
is not invoked. enter_hypervisor_head andleave_hypervisor_tail are
invoked in sync, if one is not called other one should be skipped,
otherwise guest vGIC state be out-of-date.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index bb5c610b2a..904bf48703 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -12,3 +12,4 @@ obj-y += smpboot.o
 obj-y += traps.o
 obj-y += vfp.o
 obj-y += vsysreg.o
+obj-y += vgic-v3-sr.o
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 5c18e918b0..bc851d5e26 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2044,6 +2044,27 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 {
 const union hsr hsr = { .bits = regs->hsr };
 
+if ( check_workaround_cavium_30115() )
+{
+if ( vgic_v3_handle_cpuif_access(regs) )
+{
+   /*
+* if true, g0/g1 vgic register trap is emulated for errata
+* so rest of handling of do_trap_guest_sync is not required.
+*/
+advance_pc(regs, hsr);
+/*
+ * enter_hypervisor_head is not invoked when workaround 30115
+ * is in place. enter_hypervisor_head and leave_hypervisor_tail
+ * are invoked in sync, if one is not called other one should be
+ * skipped, otherwise guest vGIC state be out-of-date.
+ */
+get_cpu_info()->skip_hyp_tail = true;
+
+return;
+}
+}
+
 enter_hypervisor_head(regs);
 
 switch (hsr.ec) {
@@ -2242,6 +2263,16 @@ void do_trap_fiq(struct cpu_user_regs *regs)
 
 void leave_hypervisor_tail(void)
 {
+/*
+ * if skip_hyp_tail is set simply retrun;
+ */
+if ( unlikely(get_cpu_info()->skip_hyp_tail) )
+{
+/* clear it, so that it is false when not handling g0/g1 traps */
+get_cpu_info()->skip_hyp_tail = false;
+return;
+}
+
 while (1)
 {
 local_irq_disable();
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 7a0971fdea..6dce06289f 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -21,7 +21,14 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
 struct cpu_info {
 struct cpu_user_regs guest_cpu_user_regs;
 unsigned long elr;
-unsigned int pad;
+/*
+ * Flag is used to skip leave_hypervisor_tail when enter_hypervisor_head
+ * is not invoked. enter_hypervisor_head andleave_hypervisor_tail are
+ * invoked in sync, if one is not called other one should be skipped,
+ * otherwise guest vGIC state be out-of-date.
+ */
+bool skip_hyp_tail:1;
+unsigned int pad:31;
 };
 
 static inline struct cpu_info *get_cpu_info(void)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 12/17] arm64: vgic-v3: Add misc Group-0 handlers

[Manish Jaggi]

This patch is ported to xen from linux commit:
eab0b2dc4f6f34147e3d10da49ab8032e15dbea0

A number of Group-0 registers can be handled by the same accessors
as that of Group-1, so let's add the required system register encodings
and catch them in the dispatching function.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index a09d7544f3..27f5139dcb 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -780,14 +780,17 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 fn = vgic_v3_write_igrpen1;
 break;
 
+case HSR_SYSREG_ICC_IAR0_EL1:
 case HSR_SYSREG_ICC_IAR1_EL1:
 fn = vgic_v3_read_iar;
 break;
 
+case HSR_SYSREG_ICC_EOIR0_EL1:
 case HSR_SYSREG_ICC_EOIR1_EL1:
 fn = vgic_v3_write_eoir;
 break;
 
+case HSR_SYSREG_ICC_HPPIR0_EL1:
 case HSR_SYSREG_ICC_HPPIR1_EL1:
 fn = vgic_v3_read_hppir;
 break;
@@ -799,6 +802,7 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
 fn = vgic_v3_write_igrpen0;
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(0):
 case HSR_SYSREG_ICC_AP1Rn_EL1(0):
 if (is_read)
 fn = vgic_v3_read_apxr0;
@@ -806,6 +810,7 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
 fn = vgic_v3_write_apxr0;
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(1):
 case HSR_SYSREG_ICC_AP1Rn_EL1(1):
 if (is_read)
 fn = vgic_v3_read_apxr1;
@@ -813,6 +818,7 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
 fn = vgic_v3_write_apxr1;
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(2):
 case HSR_SYSREG_ICC_AP1Rn_EL1(2):
 if (is_read)
 fn = vgic_v3_read_apxr2;
@@ -820,6 +826,7 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
 fn = vgic_v3_write_apxr2;
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(3):
 case HSR_SYSREG_ICC_AP1Rn_EL1(3):
 if (is_read)
 fn = vgic_v3_read_apxr3;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 0e583f820d..f83326943a 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -95,9 +95,13 @@
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
+#define HSR_SYSREG_ICC_IAR0_EL1   HSR_SYSREG(3,0,c12,c8,0)
+#define HSR_SYSREG_ICC_EOIR0_EL1  HSR_SYSREG(3,0,c12,c8,1)
+#define HSR_SYSREG_ICC_HPPIR0_EL1 HSR_SYSREG(3,0,c12,c8,2)
 #define HSR_SYSREG_ICC_BPR0_EL1  HSR_SYSREG(3,0,c12,c8,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 #define HSR_SYSREG_ICC_AP1Rn_EL1(n) HSR_SYSREG(3,0,c12,c9, n)
+#define HSR_SYSREG_ICC_AP0Rn_EL1(n) HSR_SYSREG(3,0,c12,c8,4|n)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
 #define HSR_SYSREG_PMCNTENSET_EL0 HSR_SYSREG(3,3,c9,c12,1)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 16/17] arm64: if trapping a write-to-read-only GICv3 access inject Undef exception in guest

[Manish Jaggi]

This patch is a port to xen from linux commit:
7b1dba1f7325629427c0e5bdf014159b229d16c8
KVM: arm64: Log an error if trapping a write-to-read-only GICv3 access

A write-to-read-only GICv3 access should UNDEF at EL1. But since
we're in complete paranoia-land with broken CPUs, let's assume the
worse and gracefully handle the case.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 27f5139dcb..ac39eb5e1d 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -782,6 +782,11 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 
 case HSR_SYSREG_ICC_IAR0_EL1:
 case HSR_SYSREG_ICC_IAR1_EL1:
+if ( unlikely(!is_read) )
+{
+ret = false;
+goto end;
+}
 fn = vgic_v3_read_iar;
 break;
 
@@ -792,6 +797,11 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 
 case HSR_SYSREG_ICC_HPPIR0_EL1:
 case HSR_SYSREG_ICC_HPPIR1_EL1:
+if ( unlikely(!is_read) )
+{
+ret = false;
+goto end;
+}
 fn = vgic_v3_read_hppir;
 break;
 
-- 
2.14.1


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

[Xen-devel] [PATCH v3 13/17] arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family

[Manish Jaggi]

Add MIDR values for Cavium ThunderX1 SoC family: ThunderX1, 81XX, 83XX.

This patch copies the below defines as is from linux kernel code.
arch/arm64/include/asm/cputype.h

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 222a02dd99..2f75131333 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -43,6 +43,7 @@
 })
 
 #define ARM_CPU_IMP_ARM 0x41
+#define ARM_CPU_IMP_CAVIUM  0x43
 
 #define ARM_CPU_PART_CORTEX_A12 0xC0D
 #define ARM_CPU_PART_CORTEX_A17 0xC0E
@@ -53,6 +54,10 @@
 #define ARM_CPU_PART_CORTEX_A73 0xD09
 #define ARM_CPU_PART_CORTEX_A75 0xD0A
 
+#define CAVIUM_CPU_PART_THUNDERX  0x0A1
+#define CAVIUM_CPU_PART_THUNDERX_81XX 0x0A2
+#define CAVIUM_CPU_PART_THUNDERX_83XX 0x0A3
+
 #define MIDR_CORTEX_A12 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A12)
 #define MIDR_CORTEX_A17 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A17)
 #define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
@@ -62,6 +67,10 @@
 #define MIDR_CORTEX_A73 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A73)
 #define MIDR_CORTEX_A75 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A75)
 
+#define MIDR_THUNDERX  MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX)
+#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_83XX)
+
 /* MPIDR Multiprocessor Affinity Register */
 #define _MPIDR_UP   (30)
 #define MPIDR_UP(_AC(1,U) << _MPIDR_UP)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 00/17] arm64: Mediate access to GICv3 sysregs at EL2

[Manish Jaggi]

This patchset is based on Marc's patchset below.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1].

As these patches are ported to Xen specifically for cavium errata 30115
few changes are made:
- Xen coding style is used

- group1_enable / group0_enable command line options not used.
  CONFIG_CAVIUM_ERRATUM_30115 would enable trapping of group0/1 registers

- check_workaround_cavium_30115 function is used instead to check if emulation
  has to be done.

- Not every patch in [1] is ported to xen, ported are ones which are relevant
  to Cavium Errata 30115.

Most of the trap code is added in vgic-v3-sr.c. Trap handler function is kept
independent of the usual guest trap handling code.

Cavium 30115 Errata Workaround:
  Hypervisor to trap and emulate the following registers:
  Group 0: ICC_IAR0_EL1, ICC_EOIR0_EL1, ICC_HPPIR0_EL1, ICC_BPR0_EL1,
   ICC_AP0R0_EL1, ICC_IGRPEN0_EL1
  Group 1: ICC_IAR1_EL1, ICC_EOIR1_EL1, ICC_HPPIR1_EL1, ICC_BPR1_EL1,
   ICC_AP1R0_EL1, ICC_IGRPEN1_EL1

The errata workaround has been validated on Cavium ThunderX1 platform.
Steps to reproduce the errata
- Boot Xen with 2 cores.
- Disable group1 interrupts in domU kernel
- start domU, the kill and start again.
One of the Xen core would hang.

[1] https://www.spinics.net/lists/arm-kernel/msg587082.html

Changes from v2
- remove emulate_XXX functions as per Marc's comment
- Fixed used_lrs in EOIR patch

Changes from v1
- removed __ prefix from function names
- Patches have been realigned to map closely with original patchset

Changes from v0
- Added Group0 traps.
- Some cleanups and documentation

Changes from RFC
- Added commit information on ported patches from linux
- Added skip_hyp_tail to control calling leave_hypervisor_tail 
- Added CAVIUM_CONFIG_ERRATUM_30115 which will auto enable workaround

Manish Jaggi (17):
  arm: Placeholder code to handle guest GICv3 sysreg accesses at EL2
  arm64: vgic-v3: Add ICV_BPR1_EL1 handler
  arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler
  arm64: vgic-v3: Add accessors for the ICH_APxRn_EL2 registers
  Expose ich_read/write_lr in vgic-v3-sr.c
  arm64: Add ICV_IAR1_EL1 handler
  arm64: vgic-v3: Add ICV_EOIR1_EL1 handler
  arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler
  arm64: vgic-v3: Add ICV_BPR0_EL1 handler
  arm64: vgic-v3: Add ICV_IGRPEN0_EL1 handler
  arm64: vgic-v3: Add ICV_AP1Rn_EL1 handler
  arm64: vgic-v3: Add misc Group-0 handlers
  arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family
  arm64: Add config for Cavium Thunder erratum 30115
  arm: Hook workaround handler from traps.c based on Cavium
workaround_30115
  arm64: if trapping a write-to-read-only GICv3 access inject Undef
exception in guest
  arm64: if trapping a read-from-write-only GICv3 access inject undef
exception in guest

 docs/misc/arm/silicon-errata.txt|   1 +
 xen/arch/arm/Kconfig|  11 +
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/vgic-v3-sr.c | 873 
 xen/arch/arm/cpuerrata.c|  21 +
 xen/arch/arm/traps.c|  31 ++
 xen/include/asm-arm/arm64/sysregs.h |  12 +
 xen/include/asm-arm/arm64/traps.h   |   2 +
 xen/include/asm-arm/cpuerrata.h |   1 +
 xen/include/asm-arm/cpufeature.h|   3 +-
 xen/include/asm-arm/current.h   |   9 +-
 xen/include/asm-arm/gic.h   |   1 +
 xen/include/asm-arm/gic_v3_defs.h   |  25 ++
 xen/include/asm-arm/processor.h |   9 +
 14 files changed, 998 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/arm64/vgic-v3-sr.c

-- 
2.14.1


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

[Xen-devel] [PATCH v3 09/17] arm64: vgic-v3: Add ICV_BPR0_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
423de85a98c2b50715a0784a74f6124fbc0b1548

Add a handler for reading/writing the guest's view of the ICC_BPR0_EL1
register, which is located in the ICH_VMCR_EL2.BPR0 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index c067278499..f3b6e5367c 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -280,6 +280,33 @@ static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, 
uint32_t vmcr,
 vgic_v3_write_vmcr(vmcr);
 }
 
+static void vgic_v3_read_bpr0(struct cpu_user_regs *regs, uint32_t vmcr,
+  int rt)
+{
+set_user_reg(regs, rt, vgic_v3_get_bpr0(vmcr));
+}
+
+static void vgic_v3_write_bpr0(struct cpu_user_regs *regs, uint32_t vmcr,
+   int rt)
+{
+register_t val = get_user_reg(regs, rt);
+uint8_t bpr_min = vgic_v3_bpr_min();
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR0_SHIFT;
+val &= ICH_VMCR_BPR0_MASK;
+vmcr &= ~ICH_VMCR_BPR0_MASK;
+vmcr |= val;
+
+vgic_v3_write_vmcr(vmcr);
+}
+
 static void vgic_v3_read_igrpen1(struct cpu_user_regs *regs, uint32_t vmcr,
  int rt)
 {
@@ -641,6 +668,13 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 switch ( sysreg )
 {
 
+case HSR_SYSREG_ICC_BPR0_EL1:
+if ( is_read )
+fn = vgic_v3_read_bpr0;
+else
+fn = vgic_v3_write_bpr0;
+break;
+
 case HSR_SYSREG_ICC_BPR1_EL1:
 if ( is_read )
 fn = vgic_v3_read_bpr1;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index b9230fe795..e03b6edf4d 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -94,6 +94,7 @@
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
+#define HSR_SYSREG_ICC_BPR0_EL1  HSR_SYSREG(3,0,c12,c8,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 05/17] Expose ich_read/write_lr in vgic-v3-sr.c

[Manish Jaggi]

From: Manish Jaggi <manish.ja...@cavium.com>

gicv3_ich_read/write_lr functions are duplicated in vgic-v3-sr.c
This is done to make the file independent of the xen vgic code for
handling the errata.

Both the functions in the patch are static, so this patch needs
subsequent patches to compile without error (unused function)

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index eea087902c..8e9318d959 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -39,6 +39,89 @@ static void vgic_v3_write_vmcr(uint32_t vmcr)
 WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
 }
 
+static uint64_t gicv3_ich_read_lr(int lr)
+{
+switch ( lr )
+{
+case 0: return READ_SYSREG(ICH_LR0_EL2);
+case 1: return READ_SYSREG(ICH_LR1_EL2);
+case 2: return READ_SYSREG(ICH_LR2_EL2);
+case 3: return READ_SYSREG(ICH_LR3_EL2);
+case 4: return READ_SYSREG(ICH_LR4_EL2);
+case 5: return READ_SYSREG(ICH_LR5_EL2);
+case 6: return READ_SYSREG(ICH_LR6_EL2);
+case 7: return READ_SYSREG(ICH_LR7_EL2);
+case 8: return READ_SYSREG(ICH_LR8_EL2);
+case 9: return READ_SYSREG(ICH_LR9_EL2);
+case 10: return READ_SYSREG(ICH_LR10_EL2);
+case 11: return READ_SYSREG(ICH_LR11_EL2);
+case 12: return READ_SYSREG(ICH_LR12_EL2);
+case 13: return READ_SYSREG(ICH_LR13_EL2);
+case 14: return READ_SYSREG(ICH_LR14_EL2);
+case 15: return READ_SYSREG(ICH_LR15_EL2);
+default:
+unreachable();
+}
+}
+
+static void gicv3_ich_write_lr(int lr, uint64_t val)
+{
+switch ( lr )
+{
+case 0:
+WRITE_SYSREG(val, ICH_LR0_EL2);
+break;
+case 1:
+WRITE_SYSREG(val, ICH_LR1_EL2);
+break;
+case 2:
+WRITE_SYSREG(val, ICH_LR2_EL2);
+break;
+case 3:
+WRITE_SYSREG(val, ICH_LR3_EL2);
+break;
+case 4:
+WRITE_SYSREG(val, ICH_LR4_EL2);
+break;
+case 5:
+WRITE_SYSREG(val, ICH_LR5_EL2);
+break;
+case 6:
+WRITE_SYSREG(val, ICH_LR6_EL2);
+break;
+case 7:
+WRITE_SYSREG(val, ICH_LR7_EL2);
+break;
+case 8:
+WRITE_SYSREG(val, ICH_LR8_EL2);
+break;
+case 9:
+WRITE_SYSREG(val, ICH_LR9_EL2);
+break;
+case 10:
+WRITE_SYSREG(val, ICH_LR10_EL2);
+break;
+case 11:
+WRITE_SYSREG(val, ICH_LR11_EL2);
+break;
+case 12:
+WRITE_SYSREG(val, ICH_LR12_EL2);
+break;
+case 13:
+WRITE_SYSREG(val, ICH_LR13_EL2);
+break;
+case 14:
+WRITE_SYSREG(val, ICH_LR14_EL2);
+break;
+case 15:
+WRITE_SYSREG(val, ICH_LR15_EL2);
+break;
+default:
+return;
+}
+isb();
+}
+
 static void vgic_v3_write_ap0rn(uint32_t val, int n)
 {
 switch (n)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 10/17] arm64: vgic-v3: Add ICV_IGRPEN0_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
fbc48a0011deb3d51cb657ca9c0f9083f41c0665

Add a handler for reading/writing the guest's view of the
ICC_IGRPEN0_EL1 register, which is located in the ICH_VMCR_EL2.VENG0
field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index f3b6e5367c..0fd3f929e4 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -641,6 +641,25 @@ spurious:
 set_user_reg(regs, rt, lr_val & ICH_LR_VIRTUAL_ID_MASK);
 }
 
+static void vgic_v3_read_igrpen0(struct cpu_user_regs *regs, uint32_t vmcr,
+ int rt)
+{
+set_user_reg(regs, rt, !!(vmcr & ICH_VMCR_ENG0_MASK));
+}
+
+static void vgic_v3_write_igrpen0(struct cpu_user_regs *regs, uint32_t vmcr,
+  int rt)
+{
+register_t val = get_user_reg(regs, rt);
+
+if ( val & 1 )
+vmcr |= ICH_VMCR_ENG0_MASK;
+else
+vmcr &= ~ICH_VMCR_ENG0_MASK;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
 /* vgic_v3_handle_cpuif_access
  * returns: true if the register is emulated
  *  false if not a sysreg
@@ -701,6 +720,13 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 fn = vgic_v3_read_hppir;
 break;
 
+case HSR_SYSREG_ICC_IGRPEN0_EL1:
+if (is_read)
+fn = vgic_v3_read_igrpen0;
+else
+fn = vgic_v3_write_igrpen0;
+break;
+
 default:
 ret = false;
 goto end;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index e03b6edf4d..3c4b5587a1 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -90,6 +90,7 @@
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
 #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
+#define HSR_SYSREG_ICC_IGRPEN0_EL1 HSR_SYSREG(3,0,c12,c12,6)
 #define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02

Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required (EOImode == 0).

Signed-off-by : Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 1b47351bbb..2192547cc4 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -36,6 +37,7 @@
 
 #define ICC_IAR1_EL1_SPURIOUS0x3ff
 #define VGIC_MAX_SPI 1019
+#define VGIC_MIN_LPI 8192
 
 /* Provide wrappers to read write VMCR similar to linux */
 static uint64_t vgic_v3_read_vmcr(void)
@@ -463,6 +465,134 @@ spurious:
  set_user_reg(regs, rt, ICC_IAR1_EL1_SPURIOUS);
 }
 
+static int vgic_v3_find_active_lr(int intid, uint64_t *lr_val)
+{
+int i;
+unsigned int used_lr;
+unsigned int nr_lrs =  gic_get_nr_lrs();
+unsigned long *lr_mask = (unsigned long *) _cpu(lr_mask);
+
+for_each_set_bit(used_lr, lr_mask, nr_lrs)
+{
+uint64_t val = gicv3_ich_read_lr(used_lr);
+
+if ( (val & ICH_LR_VIRTUAL_ID_MASK) == intid &&
+(val & ICH_LR_ACTIVE_BIT) )
+{
+*lr_val = val;
+return i;
+}
+}
+
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+return -1;
+}
+
+static int vgic_v3_clear_highest_active_priority(void)
+{
+int i;
+uint32_t hap = 0;
+uint8_t nr_apr_regs = vtr_to_nr_apr_regs(READ_SYSREG32(ICH_VTR_EL2));
+
+for ( i = 0; i < nr_apr_regs; i++ )
+{
+uint32_t ap0, ap1;
+int c0, c1;
+
+ap0 = vgic_v3_read_ap0rn(i);
+ap1 = vgic_v3_read_ap1rn(i);
+if ( !ap0 && !ap1 )
+{
+hap += 32;
+continue;
+}
+
+c0 = ap0 ? __ffs(ap0) : 32;
+c1 = ap1 ? __ffs(ap1) : 32;
+
+/* Always clear the LSB, which is the highest priority */
+if ( c0 < c1 )
+{
+ap0 &= ~BIT(c0);
+vgic_v3_write_ap0rn(ap0, i);
+hap += c0;
+}
+else
+{
+ap1 &= ~BIT(c1);
+vgic_v3_write_ap1rn(ap1, i);
+hap += c1;
+}
+
+/* Rescale to 8 bits of priority */
+return hap << vgic_v3_bpr_min();
+}
+
+return GICV3_IDLE_PRIORITY;
+}
+
+static void vgic_v3_clear_active_lr(int lr, uint64_t lr_val)
+{
+lr_val &= ~ICH_LR_ACTIVE_BIT;
+if ( lr_val & ICH_LR_HW )
+{
+uint32_t pid;
+
+pid = (lr_val & ICH_LR_PHYS_ID_MASK) >> ICH_LR_PHYS_ID_SHIFT;
+WRITE_SYSREG32(pid, ICC_DIR_EL1);
+}
+gicv3_ich_write_lr(lr, lr_val);
+}
+
+static void vgic_v3_bump_eoicount(void)
+{
+uint32_t hcr;
+
+hcr = READ_SYSREG32(ICH_HCR_EL2);
+hcr += 1 << ICH_HCR_EOIcount_SHIFT;
+WRITE_SYSREG32(hcr, ICH_HCR_EL2);
+}
+
+static void vgic_v3_write_eoir(struct cpu_user_regs *regs, uint32_t vmcr,
+   int rt)
+{
+uint64_t lr_val;
+uint8_t lr_prio, act_prio;
+int lr, grp;
+const union hsr hsr = { .bits = regs->hsr };
+register_t vid = get_user_reg(regs, hsr.sysreg.reg);
+
+grp = vgic_v3_get_group(hsr);
+
+/* Drop priority in any case */
+act_prio = vgic_v3_clear_highest_active_priority();
+
+/* If EOIing an LPI, no deactivate to be performed */
+if ( vid >= VGIC_MIN_LPI )
+return;
+
+/* EOImode == 1, nothing to be done here */
+if ( vmcr & ICH_VMCR_EOIM_MASK )
+return;
+
+lr = vgic_v3_find_active_lr(vid, _val);
+if ( lr == -1 )
+{
+vgic_v3_bump_eoicount();
+return;
+}
+
+lr_prio = (lr_val & ICH_LR_PRIORITY_MASK) >> ICH_LR_PRIORITY_SHIFT;
+
+/* If priorities or group do not match, the guest has fscked-up. */
+if ( grp != !!(lr_val & ICH_LR_GROUP) ||
+ vgic_v3_pri_to_pre(lr_prio, vmcr, grp) != act_prio )
+return;
+
+/* Let's now perform the deactivation */
+vgic_v3_clear_active_lr(lr, lr_val);
+}
+
 /* vgic_v3_handle_cpuif_access
  * returns: true if the register is emulated
  *  false if not a sysreg
@@ -508,6 +638,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 fn = vgic_v3_read_iar;
 break;
 
+case HSR_SYSREG_ICC_EOIR1_EL1:
+fn = vgic_v3_write_eoir;
+break;
+
 default:
 ret = false;
 goto end;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index dc8bcabe4c..f7422f1649 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -92,6 +92,7 @@
 #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
 #define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define

[Xen-devel] [PATCH v3 08/17] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

[Manish Jaggi]

This patch is ported from linux to xen
commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e
(KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler)

Add a handler for reading the guest's view of the ICV_HPPIR1_EL1
register. This is a simple parsing of the available LRs, extracting the
highest available interrupt.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 2192547cc4..c067278499 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -593,6 +593,27 @@ static void vgic_v3_write_eoir(struct cpu_user_regs *regs, 
uint32_t vmcr,
 vgic_v3_clear_active_lr(lr, lr_val);
 }
 
+static void vgic_v3_read_hppir(struct cpu_user_regs *regs, uint32_t vmcr,
+   int rt)
+{
+uint64_t lr_val;
+int lr, lr_grp, grp;
+const union hsr hsr = { .bits = regs->hsr };
+
+grp = vgic_v3_get_group(hsr);
+lr = vgic_v3_highest_priority_lr(regs, vmcr, _val);
+
+if ( lr == -1 )
+goto spurious;
+
+lr_grp = !!(lr_val & ICH_LR_GROUP);
+if ( lr_grp != grp )
+lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+spurious:
+set_user_reg(regs, rt, lr_val & ICH_LR_VIRTUAL_ID_MASK);
+}
+
 /* vgic_v3_handle_cpuif_access
  * returns: true if the register is emulated
  *  false if not a sysreg
@@ -642,6 +663,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 fn = vgic_v3_write_eoir;
 break;
 
+case HSR_SYSREG_ICC_HPPIR1_EL1:
+fn = vgic_v3_read_hppir;
+break;
+
 default:
 ret = false;
 goto end;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index f7422f1649..b9230fe795 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -93,6 +93,7 @@
 #define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
+#define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 03/17] arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
f8b630bc542e0368886ae193d3519c832b270359
KVM: arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

Add a handler for reading/writing the guest's view of ICC_IGRPEN1_EL1
register, which is located in the ICH_VMCR_EL2.VENG1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index b894398dc6..b49c53d1c5 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -93,6 +93,25 @@ static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, 
uint32_t vmcr,
 vgic_v3_write_vmcr(vmcr);
 }
 
+static void vgic_v3_read_igrpen1(struct cpu_user_regs *regs, uint32_t vmcr,
+ int rt)
+{
+set_user_reg(regs, rt, !!(vmcr & ICH_VMCR_ENG1_MASK));
+}
+
+static void vgic_v3_write_igrpen1(struct cpu_user_regs *regs, uint32_t vmcr,
+  int rt)
+{
+register_t val = get_user_reg(regs, rt);
+
+if ( val & 1 )
+vmcr |= ICH_VMCR_ENG1_MASK;
+else
+vmcr &= ~ICH_VMCR_ENG1_MASK;
+
+vgic_v3_write_vmcr(vmcr);
+}
+
 /* vgic_v3_handle_cpuif_access
  * returns: true if the register is emulated
  *  false if not a sysreg
@@ -127,6 +146,13 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 fn = vgic_v3_write_bpr1;
 break;
 
+case HSR_SYSREG_ICC_IGRPEN1_EL1:
+if ( is_read )
+fn = vgic_v3_read_igrpen1;
+else
+fn = vgic_v3_write_igrpen1;
+break;
+
 default:
 ret = false;
 goto end;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 6aa6deedfe..f4eff66380 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -90,6 +90,7 @@
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
 #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
+#define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index e247327bf0..8735ba3b1d 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -170,6 +170,8 @@
 #define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
 #define ICH_VMCR_BPR1_SHIFT  18
 #define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
+#define ICH_VMCR_ENG1_SHIFT  1
+#define ICH_VMCR_ENG1_MASK   (1 << ICH_VMCR_ENG1_SHIFT)
 
 #define ICH_LR_VIRTUAL_MASK  0x
 #define ICH_LR_VIRTUAL_SHIFT 0
-- 
2.14.1


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

[Xen-devel] [PATCH v3 14/17] arm64: Add config for Cavium Thunder erratum 30115

[Manish Jaggi]

Some Cavium Thunder CPUs suffer a problem where a Xen guest may
inadvertently cause the host kernel to quit receiving interrupts.
This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will
provide workaround.

This patch is ported to xen from linux kernel commit:
690a341577f9adf2c275ababe0dcefe91898bbf0
arm64: Add workaround for Cavium Thunder erratum 30115

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index c9854c39f4..a2546d4bb5 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -48,3 +48,4 @@ stable hypervisors.
 | ARM| Cortex-A57  | #852523 | N/A 
|
 | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
 | ARM| Cortex-A57  | #834220 | ARM64_ERRATUM_834220
|
+| CAVIUM | ThunderX1   | #30115  | CAVIUM_ERRATUM_30115
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 8174c0c635..da7e759b84 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -185,6 +185,17 @@ config ARM64_ERRATUM_834220
 
  If unsure, say Y.
 
+config CAVIUM_ERRATUM_30115
+   bool "Cavium Erratum 30115"
+   depends on HAS_GICV3
+   help
+ On ThunderX T88 pass 1.x through 2.2, T81 pass 1.0 through
+ 1.2, and T83 Pass 1.0, guest execution may disable
+ interrupts in host. Trapping both GICv3 group-0 and group-1
+ accesses sidesteps the issue.
+
+ If unsure, say Y.
+
 endmenu
 
 config HARDEN_BRANCH_PREDICTOR
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 1baa20654b..6095566085 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -271,6 +271,27 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 MIDR_RANGE(MIDR_CORTEX_A53, 0x00, 0x02),
 },
 #endif
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+{
+/* Cavium ThunderX, T88 pass 1.x - 2.2 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+{
+/* Cavium ThunderX, T81 pass 1.0 - 1.2 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x02),
+},
+{
+/* Cavium ThunderX, T83 pass 1.0 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX_83XX, 0x00, 0x00),
+},
+#endif
 #ifdef CONFIG_ARM64_ERRATUM_819472
 {
 /* Cortex-A53 r0[01] */
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 4e45b237c8..fd7135cbe8 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -27,6 +27,7 @@ static inline bool check_workaround_##erratum(void)   
  \
 
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
 CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(cavium_30115, ARM64_WORKAROUND_CAVIUM_30115, 
CONFIG_ARM_64)
 
 #undef CHECK_WORKAROUND_HELPER
 
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index e557a095af..75f32802bd 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -43,8 +43,9 @@
 #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
 #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
 #define ARM_HARDEN_BRANCH_PREDICTOR 7
+#define ARM64_WORKAROUND_CAVIUM_30115 8
 
-#define ARM_NCAPS   8
+#define ARM_NCAPS   9
 
 #ifndef __ASSEMBLY__
 
-- 
2.14.1


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

[Xen-devel] [PATCH v3 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler

This patch also imports vtr_to_nr_pre_bits macro from linux code,
from commit: d68356cc51e304ff9a389f006b6249d41f2c2319
(KVM: arm/arm64: vgic-v3: Fix nr_pre_bits bitfield extraction)

Since the macro is a dependency both are merged in a single patch

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 4cc077fbb6..b894398dc6 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -21,10 +21,13 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)
+
 /* Provide wrappers to read write VMCR similar to linux */
 static uint64_t vgic_v3_read_vmcr(void)
 {
@@ -36,6 +39,60 @@ static void vgic_v3_write_vmcr(uint32_t vmcr)
 WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
 }
 
+static int vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, uint32_t vmcr,
+  int rt)
+{
+set_user_reg(regs, rt, vgic_v3_get_bpr1(vmcr));
+}
+
+static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, uint32_t vmcr,
+   int rt)
+{
+register_t val = get_user_reg(regs, rt);
+uint8_t bpr_min = vgic_v3_bpr_min();
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+vgic_v3_write_vmcr(vmcr);
+}
+
 /* vgic_v3_handle_cpuif_access
  * returns: true if the register is emulated
  *  false if not a sysreg
@@ -62,6 +119,14 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
 
 switch ( sysreg )
 {
+
+case HSR_SYSREG_ICC_BPR1_EL1:
+if ( is_read )
+fn = vgic_v3_read_bpr1;
+else
+fn = vgic_v3_write_bpr1;
+break;
+
 default:
 ret = false;
 goto end;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 1811234249..6aa6deedfe 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -89,6 +89,7 @@
 #define HSR_SYSREG_ICC_ASGI1R_EL1 HSR_SYSREG(3,1,c12,c11,6)
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
+#define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 10a2aeea93..e247327bf0 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -164,6 +164,12 @@
 #define ICH_VMCR_VENG1   (1 << 1)
 #define ICH_VMCR_PRIORITY_MASK   0xff
 #define ICH_VMCR_PRIORITY_SHIFT  24
+#define ICH_VMCR_CBPR_SHIFT  4
+#define ICH_VMCR_CBPR_MASK   (1 << ICH_VMCR_CBPR_SHIFT)
+#define ICH_VMCR_BPR0_SHIFT  21
+#define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
+#define ICH_VMCR_BPR1_SHIFT  18
+#define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
 
 #define ICH_LR_VIRTUAL_MASK  0x
 #define ICH_LR_VIRTUAL_SHIFT 0
-- 
2.14.1


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

[Xen-devel] [PATCH v3 01/17] arm: Placeholder code to handle guest GICv3 sysreg accesses at EL2

[Manish Jaggi]

From: Manish Jaggi <manish.ja...@cavium.com>

The errata will require emulation of GIC virtual CPU interface in Xen.
Because the hypervisor will update its internal state of the vGIC, we
want to avoid messing up with it. So the errata is handled separately
from the rest of the hypervisor.

New file vgic-v3-sr.c is added which will hold trap and emulate code
for group0 / group1 registers.

vgic_v3_handle_cpuif_access would be called from do_trap_guest_sync
(xen/arch/arm/traps.c) in subsequent patches based on
check_errata_workaround macro.

This patch takes some code from linux commit:
59da1cbfd840d69bd7a310249924da3fc202c417
(KVM: arm64: vgic-v3: Add hook to handle guest GICv3 sysreg accesses at
EL2)

vgic_v3_read/write_vmcr functions are imported from linux commit:
commit 328e566479449194979d64685ae6d74c989599bb
(KVM: arm/arm64: vgic: Defer touching GICH_VMCR to vcpu_load/put)
Since only two small functions are imported and is a dependency to match
imported linux code single patch is used.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
new file mode 100644
index 00..4cc077fbb6
--- /dev/null
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -0,0 +1,86 @@
+/*
+ * xen/arch/arm/arm64/vgic-v3-sr.c
+ *
+ * Code to emulate group0/group1 traps for handling
+ * cavium erratum 30115
+ *
+ * This file merges code from Linux virt/kvm/arm/hyp/vgic-v3-sr.c
+ * which is : Copyright (C) 2012-2015 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyng...@arm.com>
+ *
+ * Xen-Merge: Manish Jaggi <manish.ja...@cavium.com>
+ *
+ * Ths program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* Provide wrappers to read write VMCR similar to linux */
+static uint64_t vgic_v3_read_vmcr(void)
+{
+return READ_SYSREG32(ICH_VMCR_EL2);
+}
+
+static void vgic_v3_write_vmcr(uint32_t vmcr)
+{
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+/* vgic_v3_handle_cpuif_access
+ * returns: true if the register is emulated
+ *  false if not a sysreg
+ */
+bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
+{
+int rt;
+uint32_t vmcr;
+void (*fn)(struct cpu_user_regs *, u32, int);
+bool is_read;
+uint32_t sysreg;
+bool ret = true;
+const union hsr hsr = { .bits = regs->hsr };
+
+sysreg = hsr.bits & HSR_SYSREG_REGS_MASK;
+is_read = hsr.sysreg.read;
+/* Disabling interrupts to prevent change in guest state */
+local_irq_disable();
+if ( hsr.ec != HSR_EC_SYSREG )
+{
+ret = false;
+goto end;
+}
+
+switch ( sysreg )
+{
+default:
+ret = false;
+goto end;
+}
+/* Call the emulation hander */
+vmcr = vgic_v3_read_vmcr();
+rt = hsr.sysreg.reg;
+fn(regs, vmcr, rt);
+end:
+local_irq_enable();
+
+return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/traps.h 
b/xen/include/asm-arm/arm64/traps.h
index 2379b578cb..3c3911a69c 100644
--- a/xen/include/asm-arm/arm64/traps.h
+++ b/xen/include/asm-arm/arm64/traps.h
@@ -3,6 +3,8 @@
 
 void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len);
 
+bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs);
+
 void do_sysreg(struct cpu_user_regs *regs,
const union hsr hsr);
 
-- 
2.14.1


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

[Xen-devel] [PATCH v3 11/17] arm64: vgic-v3: Add ICV_AP1Rn_EL1 handler

[Manish Jaggi]

This patch is a xen port of linux commit
f9e7449c780f688bf61a13dfa8c344afeb4ad6e0.

Add a handler for reading/writing the guest's view of the ICV_AP1Rn_EL1
registers. We just map them to the corresponding ICH_AP(1)Rn_EL2
registers.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 0fd3f929e4..a09d7544f3 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -660,6 +660,78 @@ static void vgic_v3_write_igrpen0(struct cpu_user_regs 
*regs, uint32_t vmcr,
 WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
 }
 
+static void vgic_v3_read_apxrn(struct cpu_user_regs *regs, int rt, int n)
+{
+uint32_t val;
+const union hsr hsr = { .bits = regs->hsr };
+
+if ( !vgic_v3_get_group(hsr) )
+val = vgic_v3_read_ap0rn(n);
+else
+val = vgic_v3_read_ap1rn(n);
+
+set_user_reg(regs, rt, val);
+}
+
+static void vgic_v3_write_apxrn(struct cpu_user_regs *regs, int rt, int n)
+{
+u32 val = get_user_reg(regs, rt);
+const union hsr hsr = { .bits = regs->hsr };
+
+if ( !vgic_v3_get_group(hsr) )
+vgic_v3_write_ap0rn(val, n);
+else
+vgic_v3_write_ap1rn(val, n);
+}
+
+static void vgic_v3_read_apxr0(struct cpu_user_regs *regs, uint32_t vmcr,
+   int rt)
+{
+vgic_v3_read_apxrn(regs, rt, 0);
+}
+
+static void vgic_v3_read_apxr1(struct cpu_user_regs *regs, uint32_t vmcr,
+   int rt)
+{
+vgic_v3_read_apxrn(regs, rt, 1);
+}
+
+static void vgic_v3_read_apxr2(struct cpu_user_regs *regs, uint32_t vmcr,
+   int rt)
+{
+vgic_v3_read_apxrn(regs, rt, 2);
+}
+
+static void vgic_v3_read_apxr3(struct cpu_user_regs *regs, uint32_t vmcr,
+   int rt)
+{
+vgic_v3_read_apxrn(regs, rt, 3);
+}
+
+static void vgic_v3_write_apxr0(struct cpu_user_regs *regs, uint32_t vmcr,
+int rt)
+{
+vgic_v3_write_apxrn(regs, rt, 0);
+}
+
+static void vgic_v3_write_apxr1(struct cpu_user_regs *regs, uint32_t vmcr,
+int rt)
+{
+vgic_v3_write_apxrn(regs, rt, 1);
+}
+
+static void vgic_v3_write_apxr2(struct cpu_user_regs *regs, uint32_t vmcr,
+int rt)
+{
+vgic_v3_write_apxrn(regs, rt, 2);
+}
+
+static void vgic_v3_write_apxr3(struct cpu_user_regs *regs, uint32_t vmcr,
+int rt)
+{
+vgic_v3_write_apxrn(regs, rt, 3);
+}
+
 /* vgic_v3_handle_cpuif_access
  * returns: true if the register is emulated
  *  false if not a sysreg
@@ -727,6 +799,34 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 fn = vgic_v3_write_igrpen0;
 break;
 
+case HSR_SYSREG_ICC_AP1Rn_EL1(0):
+if (is_read)
+fn = vgic_v3_read_apxr0;
+else
+fn = vgic_v3_write_apxr0;
+break;
+
+case HSR_SYSREG_ICC_AP1Rn_EL1(1):
+if (is_read)
+fn = vgic_v3_read_apxr1;
+else
+fn = vgic_v3_write_apxr1;
+break;
+
+case HSR_SYSREG_ICC_AP1Rn_EL1(2):
+if (is_read)
+fn = vgic_v3_read_apxr2;
+else
+fn = vgic_v3_write_apxr2;
+break;
+
+case HSR_SYSREG_ICC_AP1Rn_EL1(3):
+if (is_read)
+fn = vgic_v3_read_apxr3;
+else
+fn = vgic_v3_write_apxr3;
+break;
+
 default:
 ret = false;
 goto end;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 3c4b5587a1..0e583f820d 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -97,6 +97,7 @@
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
 #define HSR_SYSREG_ICC_BPR0_EL1  HSR_SYSREG(3,0,c12,c8,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
+#define HSR_SYSREG_ICC_AP1Rn_EL1(n) HSR_SYSREG(3,0,c12,c9, n)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
 #define HSR_SYSREG_PMCNTENSET_EL0 HSR_SYSREG(3,3,c9,c12,1)
-- 
2.14.1


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

[Xen-devel] [PATCH v3 06/17] arm64: Add ICV_IAR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
132a324ab62fe4fb8d6dcc2ab4eddb0e93b69afe.

Add a handler for reading the guest's view of the ICC_IAR1_EL1
register. This involves finding the highest priority Group-1
interrupt, checking against both PMR and the active group
priority, activating the interrupt and setting the group
priority as active.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 8e9318d959..1b47351bbb 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -25,8 +25,17 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)
+#define vtr_to_nr_apr_regs(v) (1 << (vtr_to_nr_pre_bits(v) - 5))
+
+#define ESR_ELx_SYS64_ISS_CRM_SHIFT 1
+#define ESR_ELx_SYS64_ISS_CRM_MASK (0xf << ESR_ELx_SYS64_ISS_CRM_SHIFT)
+
+#define ICC_IAR1_EL1_SPURIOUS0x3ff
+#define VGIC_MAX_SPI 1019
 
 /* Provide wrappers to read write VMCR similar to linux */
 static uint64_t vgic_v3_read_vmcr(void)
@@ -288,6 +297,172 @@ static void vgic_v3_write_igrpen1(struct cpu_user_regs 
*regs, uint32_t vmcr,
 vgic_v3_write_vmcr(vmcr);
 }
 
+static int vgic_v3_get_group(const union hsr hsr)
+{
+uint8_t crm = (hsr.bits & ESR_ELx_SYS64_ISS_CRM_MASK) >>
+   ESR_ELx_SYS64_ISS_CRM_SHIFT;
+
+return crm != 8;
+}
+
+static int vgic_v3_highest_priority_lr(struct cpu_user_regs *regs,
+   uint32_t vmcr, uint64_t *lr_val)
+{
+unsigned int i, lr = -1;
+unsigned int used_lrs =  gic_get_nr_lrs();
+uint8_t priority = GICV3_IDLE_PRIORITY;
+
+for ( i = 0; i < used_lrs; i++ )
+{
+uint64_t val =  gicv3_ich_read_lr(i);
+uint8_t lr_prio = (val & ICH_LR_PRIORITY_MASK) >> 
ICH_LR_PRIORITY_SHIFT;
+
+/* Not pending in the state? */
+if ( (val & ICH_LR_STATE) != ICH_LR_PENDING_BIT )
+continue;
+
+/* Group-0 interrupt, but Group-0 disabled? */
+if ( !(val & ICH_LR_GROUP) && !(vmcr & ICH_VMCR_ENG0_MASK) )
+continue;
+
+/* Group-1 interrupt, but Group-1 disabled? */
+if ( (val & ICH_LR_GROUP) && !(vmcr & ICH_VMCR_ENG1_MASK) )
+continue;
+
+/* Not the highest priority? */
+if ( lr_prio >= priority )
+continue;
+
+/* This is a candidate */
+priority = lr_prio;
+*lr_val = val;
+lr = i;
+}
+
+if ( lr == -1 )
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+return lr;
+}
+
+static int vgic_v3_get_highest_active_priority(void)
+{
+unsigned int i;
+uint32_t hap = 0;
+uint8_t nr_apr_regs = vtr_to_nr_apr_regs(READ_SYSREG32(ICH_VTR_EL2));
+
+for ( i = 0; i < nr_apr_regs; i++ )
+{
+uint32_t val;
+
+/*
+ * The ICH_AP0Rn_EL2 and ICH_AP1Rn_EL2 registers
+ * contain the active priority levels for this VCPU
+ * for the maximum number of supported priority
+ * levels, and we return the full priority level only
+ * if the BPR is programmed to its minimum, otherwise
+ * we return a combination of the priority level and
+ * subpriority, as determined by the setting of the
+ * BPR, but without the full subpriority.
+ */
+val  = vgic_v3_read_ap0rn(i);
+val |= vgic_v3_read_ap1rn(i);
+if ( !val )
+{
+hap += 32;
+continue;
+}
+
+return (hap +  __ffs(val)) << vgic_v3_bpr_min();
+}
+
+return GICV3_IDLE_PRIORITY;
+}
+
+/*
+ * Convert a priority to a preemption level, taking the relevant BPR
+ * into account by zeroing the sub-priority bits.
+ */
+static uint8_t vgic_v3_pri_to_pre(uint8_t pri, uint32_t vmcr, int grp)
+{
+unsigned int bpr;
+
+if ( !grp )
+bpr = vgic_v3_get_bpr0(vmcr) + 1;
+else
+bpr = vgic_v3_get_bpr1(vmcr);
+
+return pri & (GENMASK(7, 0) << bpr);
+}
+
+/*
+ * The priority value is independent of any of the BPR values, so we
+ * normalize it using the minumal BPR value. This guarantees that no
+ * matter what the guest does with its BPR, we can always set/get the
+ * same value of a priority.
+ */
+static void vgic_v3_set_active_priority(uint8_t pri, uint32_t vmcr, int grp)
+{
+uint8_t pre, ap;
+uint32_t val;
+int apr;
+
+pre = vgic_v3_pri_to_pre(pri, vmcr, grp);
+ap = pre >> vgic_v3_bpr_min();
+apr = ap / 32;
+
+if ( !grp )
+{
+val = vgic_v3_read_ap0rn(apr);
+vgic_v3_write_ap0rn(val | BIT(ap % 32), apr);
+}
+else
+{
+val = vgic_v3_read_ap1rn(apr);
+vgic_v3_write_ap1rn(val | BIT(ap % 32), apr);
+}
+}
+
+static void vgic_v3_read_iar(struct cpu_user_regs *regs, uint32_t vmcr, int rt)
+{
+uint64_

[Xen-devel] [PATCH v3 04/17] arm64: vgic-v3: Add accessors for the ICH_APxRn_EL2 registers

[Manish Jaggi]

This patch is ported to xen from linux commit
63000dd8006dc987db31ba670edc23142ea91e01
KVM: arm/arm64: vgic-v3: Add accessors for the ICH_APxRn_EL2 registers

As we're about to access the Active Priority registers a lot more,
let's define accessors that take the register number as a parameter.

This patch only has accessors, it does not modify the vgic code.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index b49c53d1c5..eea087902c 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -39,6 +39,99 @@ static void vgic_v3_write_vmcr(uint32_t vmcr)
 WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
 }
 
+static void vgic_v3_write_ap0rn(uint32_t val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP0R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP0R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP0R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+static void vgic_v3_write_ap1rn(uint32_t val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP1R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP1R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP1R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+static uint32_t vgic_v3_read_ap0rn(int n)
+{
+uint32_t val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP0R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP0R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP0R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
+static uint32_t vgic_v3_read_ap1rn(int n)
+{
+uint32_t val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP1R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP1R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP1R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
+
 static int vgic_v3_bpr_min(void)
 {
 /* See Pseudocode for VPriorityGroup */
-- 
2.14.1


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

Re: [Xen-devel] [v2 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

Hi Sameer,

General Comment, please use appropriate variable names for XXX_domain 
structures in code which is xen specific.



On 05/24/2018 06:16 AM, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- xen/linux_compat: Add a Linux compat header
   For porting files directly from Linux it is useful to have a function mapping
   definitions from Linux to Xen. This file adds common API functions and
   other defines that are needed for porting arm SMMU drivers.

Signed-off-by: Sameer Goel 
---
  xen/arch/arm/p2m.c|   1 +
  xen/drivers/Kconfig   |   2 +
  xen/drivers/passthrough/arm/Kconfig   |   8 +
  xen/drivers/passthrough/arm/Makefile  |   1 +
  xen/drivers/passthrough/arm/smmu-v3.c | 934 +-
  xen/include/xen/linux_compat.h|  84 +++
  6 files changed, 1001 insertions(+), 29 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/Kconfig
  create mode 100644 xen/include/xen/linux_compat.h

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..38aa9f00c1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1454,6 +1454,7 @@ err:
  static void __init setup_virt_paging_one(void *data)
  {
  unsigned long val = (unsigned long)data;
+/* SMMUv3 S2 cfg vtcr reuses the following value */
  WRITE_SYSREG32(val, VTCR_EL2);
  isb();
  }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index db94393f47..59ca00f850 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -15,4 +15,6 @@ source "drivers/video/Kconfig"
  config HAS_VPCI
bool
  
+source "drivers/passthrough/arm/Kconfig"

+
  endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
  obj-y += iommu.o
  obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..df81626785 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,414 @@
   * Author: Will Deacon 
   *
   * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
   */
  
-#include 

-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "io-pgtable.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if 

Re: [Xen-devel] [PATCH 5/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

On 04/19/2018 04:24 PM, Manish Jaggi wrote:

Sorry for top posting,

is someone working on the comments on this patch?

-Manish

If no one is working this code anymore, I would like to pick it up and 
continue maintaining it.

Is it fine with all?

-Regards
Manish


On 03/10/2018 11:23 PM, Manish Jaggi wrote:

Hi Sameer,


On 02/09/2018 08:40 AM, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- xen/linux_compat: Add a Linux compat header
   For porting files directly from Linux it is useful to have a 
function mapping
   definitions from Linux to Xen. This file adds common API 
functions and

   other defines that are needed for porting arm SMMU drivers.

Signed-off-by: Sameer Goel <sameer.g...@linaro.org>
---
  xen/arch/arm/p2m.c    |   1 +
  xen/drivers/Kconfig   |   2 +
  xen/drivers/passthrough/arm/Kconfig   |   8 +
  xen/drivers/passthrough/arm/Makefile  |   1 +
  xen/drivers/passthrough/arm/smmu-v3.c | 892 
--

  xen/include/xen/linux_compat.h    |  84 
  6 files changed, 959 insertions(+), 29 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/Kconfig
  create mode 100644 xen/include/xen/linux_compat.h

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 65e8b9c6ea..fef7605fd6 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1460,6 +1460,7 @@ err:
  static void __init setup_virt_paging_one(void *data)
  {
  unsigned long val = (unsigned long)data;
+    /* SMMUv3 S2 cfg vtcr reuses the following value */
  WRITE_SYSREG32(val, VTCR_EL2);
  isb();
  }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index bc3a54f0ea..612655386d 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
    source "drivers/video/Kconfig"
  +source "drivers/passthrough/arm/Kconfig"
+
  endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig

new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+    bool "ARM SMMUv3 Support"
+    depends on ARM_64
+    help
+ Support for implementations of the ARM System MMU architecture
+ version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile

index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
  obj-y += iommu.o
  obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c

index e67ba6c40f..f43485fe6e 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,414 @@
   * Author: Will Deacon <will.dea...@arm.com>
   *
   * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel <sameer.g...@linaro.org>
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) 
(!dt_property_read_u32(np, pname, out))

+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+    u64 addr;
+    u64 size;
+    unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct 
platform_device *pdev,

+  unsigned int type,
+  unsigned int num)
+{
+    /*
+ * The resource is only used between 2 calls of 
platform_get_resource.

+ * It's quite ugly but it's avoid to add too much code in the part
+ * imported from Linux
+ */
+    static struct resource res;
+    struct acpi_iort_node *iort_node;
+    struct acpi_iort_smmu_v3 *node_smmu_data;
+    int ret = 0;
+
+    res.type = type;
+
+    switch (type) {
+    case IORESOURCE_MEM:
+    if (pdev->type == DEV_ACP

Re: [Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[Manish Jaggi]

On 04/05/2018 03:10 PM, Julien Grall wrote:

Hi,

On 02/04/18 12:17, Manish Jaggi wrote:



On 04/02/2018 04:33 PM, Manish Jaggi wrote:


On 03/27/2018 03:48 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required (EOImode == 0).

Signed-off-by : Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/arm64/vgic-v3-sr.c | 136 


  xen/include/asm-arm/arm64/sysregs.h |   1 +
  xen/include/asm-arm/gic_v3_defs.h   |   4 ++
  3 files changed, 141 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c 
b/xen/arch/arm/arm64/vgic-v3-sr.c

index 026d64506f..e32ec01f56 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -33,6 +33,7 @@
    #define ICC_IAR1_EL1_SPURIOUS    0x3ff
  #define VGIC_MAX_SPI 1019
+#define VGIC_MIN_LPI 8192
    static int vgic_v3_bpr_min(void)
  {
@@ -482,6 +483,137 @@ static void vreg_emulate_iar(struct 
cpu_user_regs *regs, const union hsr hsr)

  vgic_v3_read_iar(regs, hsr);
  }
  +static int vgic_v3_find_active_lr(int intid, uint64_t *lr_val)
+{
+    int i;
+    unsigned int used_lrs =  gic_get_num_lrs();

This is quite a departure from the existing code. KVM always allocate
LRs sequentially, and used_lrs represents the current upper bound.

IIUC, Xen uses a function gic_find_unused_lr to find an unused LR.

xen/arch/arm/gic.c:
gic_raise_guest_irq
    gic_find_unused_lr

Here,
you seem to be looking at *all* the LRs. Is that safe?
IIUC Xen does not maintain a used_lrs, it does have an lr_mask, but 
that is static in gic.c


To do something like
+for_each_set_bit(i, lr_mask, nr_lrs)
+ {
+  u64 val = __gic_v3_get_lr(i);
+  u8 lr_prio = (val & ICH_LR_PRIORITY_MASK) >> 
ICH_LR_PRIORITY_SHIFT;

+     /* Not pending in the state? */
+ if ((val & ICH_LR_STATE) != ICH_LR_PENDING_BIT)
+ continue;


I need to do some jugglery to make lr_mask visible outside of 
xen/arch/arm/gic.c
The easiest would be to add an extern function, harder way would be 
to add it in gic_hw_operations


- vgic_v3_highest_priority_lr iterates is interested in used LR's 
which sre in Pending state.

- emulating IAR is done with interrupts disabled
- iterating over all the LRs and finding which ones are in Pending.


Just to add I was answering for using num_lrs for used_lrs, above was 
for IAR flow.

This holds the same for EOIR flow as well.

The bigger point is unless I add some jugglery to access static value 
outside gic.c

this is the only solution.

Stefano/Andre/Julien
Please suggest if there is some better way...


lr_mask is already exported. So I am not sure what you need here.

However, despite the fact the variable is living in gic.c it is only 
used by the old vGIC. Newer vGIC is based on KVM, so used_lrs would be 
fine to use.



So I should send the next version based on old vGIC or new vGIC ?

For the old vGIC, see below.


  Are you
guaranteed not to have any stale state?


LRs are zeroed when unused and AFAICT they should always be accurate. 
Stefano can you confirm it?


So it would be ok go through all the LRs (thought with a performance 
hit).


Cheers,




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

Re: [Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[Manish Jaggi]

On 04/02/2018 04:33 PM, Manish Jaggi wrote:


On 03/27/2018 03:48 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required (EOImode == 0).

Signed-off-by : Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/arm64/vgic-v3-sr.c | 136 


  xen/include/asm-arm/arm64/sysregs.h |   1 +
  xen/include/asm-arm/gic_v3_defs.h   |   4 ++
  3 files changed, 141 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c 
b/xen/arch/arm/arm64/vgic-v3-sr.c

index 026d64506f..e32ec01f56 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -33,6 +33,7 @@
    #define ICC_IAR1_EL1_SPURIOUS    0x3ff
  #define VGIC_MAX_SPI 1019
+#define VGIC_MIN_LPI 8192
    static int vgic_v3_bpr_min(void)
  {
@@ -482,6 +483,137 @@ static void vreg_emulate_iar(struct 
cpu_user_regs *regs, const union hsr hsr)

  vgic_v3_read_iar(regs, hsr);
  }
  +static int vgic_v3_find_active_lr(int intid, uint64_t *lr_val)
+{
+    int i;
+    unsigned int used_lrs =  gic_get_num_lrs();

This is quite a departure from the existing code. KVM always allocate
LRs sequentially, and used_lrs represents the current upper bound.

IIUC, Xen uses a function gic_find_unused_lr to find an unused LR.

xen/arch/arm/gic.c:
gic_raise_guest_irq
    gic_find_unused_lr

Here,
you seem to be looking at *all* the LRs. Is that safe?
IIUC Xen does not maintain a used_lrs, it does have an lr_mask, but 
that is static in gic.c


To do something like
+for_each_set_bit(i, lr_mask, nr_lrs)
+ {
+  u64 val = __gic_v3_get_lr(i);
+  u8 lr_prio = (val & ICH_LR_PRIORITY_MASK) >> 
ICH_LR_PRIORITY_SHIFT;

+     /* Not pending in the state? */
+ if ((val & ICH_LR_STATE) != ICH_LR_PENDING_BIT)
+ continue;


I need to do some jugglery to make lr_mask visible outside of 
xen/arch/arm/gic.c
The easiest would be to add an extern function, harder way would be to 
add it in gic_hw_operations


- vgic_v3_highest_priority_lr iterates is interested in used LR's 
which sre in Pending state.

- emulating IAR is done with interrupts disabled
- iterating over all the LRs and finding which ones are in Pending.


Just to add I was answering for using num_lrs for used_lrs, above was 
for IAR flow.

This holds the same for EOIR flow as well.

The bigger point is unless I add some jugglery to access static value 
outside gic.c

this is the only solution.

Stefano/Andre/Julien
Please suggest if there is some better way...

  Are you
guaranteed not to have any stale state?

I would request Stefano/Andre/Julien to comment here...


In any case, the change should be documented.


+
+    for ( i = 0; i < used_lrs; i++ )
+    {
+    uint64_t val = gicv3_ich_read_lr(i);
+
+    if ( (val & ICH_LR_VIRTUAL_ID_MASK) == intid &&
+    (val & ICH_LR_ACTIVE_BIT) )
+    {
+    *lr_val = val;
+    return i;
+    }
+    }
+
+    *lr_val = ICC_IAR1_EL1_SPURIOUS;
+    return -1;
+}

Thanks,

M.





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

Re: [Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[Manish Jaggi]

On 03/27/2018 03:48 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required (EOImode == 0).

Signed-off-by : Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/arm64/vgic-v3-sr.c | 136 
  xen/include/asm-arm/arm64/sysregs.h |   1 +
  xen/include/asm-arm/gic_v3_defs.h   |   4 ++
  3 files changed, 141 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 026d64506f..e32ec01f56 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -33,6 +33,7 @@
  
  #define ICC_IAR1_EL1_SPURIOUS0x3ff

  #define VGIC_MAX_SPI 1019
+#define VGIC_MIN_LPI 8192
  
  static int vgic_v3_bpr_min(void)

  {
@@ -482,6 +483,137 @@ static void vreg_emulate_iar(struct cpu_user_regs *regs, 
const union hsr hsr)
  vgic_v3_read_iar(regs, hsr);
  }
  
+static int vgic_v3_find_active_lr(int intid, uint64_t *lr_val)

+{
+int i;
+unsigned int used_lrs =  gic_get_num_lrs();

This is quite a departure from the existing code. KVM always allocate
LRs sequentially, and used_lrs represents the current upper bound.

IIUC, Xen uses a function gic_find_unused_lr to find an unused LR.

xen/arch/arm/gic.c:
gic_raise_guest_irq
    gic_find_unused_lr

Here,
you seem to be looking at *all* the LRs. Is that safe?
IIUC Xen does not maintain a used_lrs, it does have an lr_mask, but that 
is static in gic.c


To do something like
+for_each_set_bit(i, lr_mask, nr_lrs)
+ {
+  u64 val = __gic_v3_get_lr(i);
+  u8 lr_prio = (val & ICH_LR_PRIORITY_MASK) >> ICH_LR_PRIORITY_SHIFT;
+     /* Not pending in the state? */
+ if ((val & ICH_LR_STATE) != ICH_LR_PENDING_BIT)
+ continue;


I need to do some jugglery to make lr_mask visible outside of 
xen/arch/arm/gic.c
The easiest would be to add an extern function, harder way would be to 
add it in gic_hw_operations


- vgic_v3_highest_priority_lr iterates is interested in used LR's which 
sre in Pending state.

- emulating IAR is done with interrupts disabled
- iterating over all the LRs and finding which ones are in Pending.



  Are you
guaranteed not to have any stale state?

I would request Stefano/Andre/Julien to comment here...


In any case, the change should be documented.


+
+for ( i = 0; i < used_lrs; i++ )
+{
+uint64_t val = gicv3_ich_read_lr(i);
+
+if ( (val & ICH_LR_VIRTUAL_ID_MASK) == intid &&
+(val & ICH_LR_ACTIVE_BIT) )
+{
+*lr_val = val;
+return i;
+}
+}
+
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+return -1;
+}

Thanks,

M.



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

Re: [Xen-devel] [PATCH resend 02/13] acpi: arm: query estimated size of hardware domain's IORT.

[Manish Jaggi]

Hi Julien,

On 03/21/2018 03:42 PM, Julien Grall wrote:

Title: Please drop the full stop.

On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
...


+    struct rid_devid_map *rmap;


I am sorry but I still don't see any comment about my comment on the 
previous version. For reminder:


"A bit more documention of this function would be appreciated. For 
instance, the rationale between browsing the list twice for allocation.


I actually do think this might be avoidable by storing a bit more 
information from the IORT. From the table you can easily deduced the 
number of root complex and ITS group. 

That will still require parsing of all IORT nodes.
I am add one more api to return total mappings, which would basically 
return a counter which is updated when add_rid_deviceid_map is called.

This would replace

+    list_for_each_entry(rmap, _devid_list, entry)
+    count++;
+

Sounds good?

They could be store with the rest of information."




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

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

On 03/27/2018 05:08 PM, Marc Zyngier wrote:

On 27/03/18 12:27, Manish Jaggi wrote:


On 03/27/2018 04:55 PM, Marc Zyngier wrote:

On 27/03/18 12:15, Manish Jaggi wrote:

On 03/27/2018 04:41 PM, Marc Zyngier wrote:

On 27/03/18 12:07, Manish Jaggi wrote:

On 03/27/2018 04:35 PM, Marc Zyngier wrote:

On 27/03/18 11:56, Manish Jaggi wrote:

On 03/27/2018 04:15 PM, Marc Zyngier wrote:

On 27/03/18 11:35, Manish Jaggi wrote:

On 03/27/2018 04:00 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
   xen/arch/arm/arm64/vgic-v3-sr.c | 70 
+
   xen/include/asm-arm/arm64/sysregs.h |  1 +
   xen/include/asm-arm/gic_v3_defs.h   |  6 
   3 files changed, 77 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 39ab1ed6ca..ed4254acf9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -18,10 +18,76 @@
*/
   
   #include 

+#include 
   #include 
   #include 
   #include 
   
+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)

+
+static int vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, vgic_v3_get_bpr1(vmcr));
+}
+
+static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_bpr1(struct cpu_user_regs *regs, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_bpr1(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
+}
+
   /*
* returns true if the register is emulated.
*/
@@ -40,6 +106,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
   
   switch ( hsr.bits & HSR_SYSREG_REGS_MASK )

   {
+case HSR_SYSREG_ICC_BPR1_EL1:
+ vreg_emulate_bpr1(regs, hsr);
+ break;

What is the rational for indirecting through a function and moving the
reading of VMCR to the leaf functions? I appreciate that this doesn't
change much, but since this is a port of existing code, it will make
more complex the port of potential fixes.

I used xen template of handling sysreg traps
If you see the file xen/arch/arm/arm64/sysreg.c
a handle_XXX function is used throughout...

Sure, but this is not sysreg.c. This is a separate file for a reason
(i.e. it is imported code). Anyway, that's for the Xen maintainers to
decide.

More importantly, my other question still stand: most trap functions do
require VMCR as an input. Why moving it to the leaf functions?

Same reason, I was keeping the interface same of all handle_XXX functions
handle_XXX(regs, hsr, ...)

Do you want me to change both to match with your patch or it is ok?

My preference would be to keep the code as initially written, as you're
pointlessly changing the flow. Again, that's for the maintainers to
comment, but you should at the very least indicate that change in the
commit log.

I did in the cover letter

which, crucially, doesn't end-up in the commit. Oh well.

I am working on to address the two points, will send v3 later today.
- will remove emulate functions
- and pass vmcr as a param.

Will it be possible to review the remaining part of the code, so that I
can address
other comments in v3 as well.

I suggest you wait until some other folks have a chance to properly
review the series. You only posted the stuff this morning, give them a
chance. A week between two versions is probably the right timing.

Xen 4.11 

Re: [Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

[Manish Jaggi]

On 03/28/2018 06:18 AM, Julien Grall wrote:


Hi,

Sorry for the formatting.

On Wed, 28 Mar 2018, 04:18 Stefano Stabellini, <sstabell...@kernel.org 
<mailto:sstabell...@kernel.org>> wrote:


On Tue, 27 Mar 2018, Marc Zyngier wrote:
> On 27/03/18 11:10, Manish Jaggi wrote:
> >
> >
> > On 03/27/2018 03:31 PM, Marc Zyngier wrote:
    > >> On 27/03/18 10:07, Manish Jaggi wrote:
> >>> The errata will require to emulate the GIC virtual CPU
interface in Xen.
> >>> Because the hypervisor will update its internal state of the
vGIC, we want
> >>> to avoid messing up with it. So the errata is handled
separately from the
> >>> rest of the hypervisor.
> >>>
> >>> New file vgic-v3-sr.c is added which will hold trap and
emulate code
> >>> for group0 / group1 registers. Workaround for cavium Errata
30115
> >>> needs this emulation code.
> >>>
> >>> vgic_v3_handle_cpuif_access would be called from
do_trap_guest_sync
> >>> in subsequent patches based on errata macros.
> >>>
> >>> Signed-off-by: Manish Jaggi <manish.ja...@cavium.com
<mailto:manish.ja...@cavium.com>>
> >>> ---
> >>>   xen/arch/arm/arm64/vgic-v3-sr.c   | 60
+++
> >>>   xen/include/asm-arm/arm64/traps.h |  2 ++
> >>>   2 files changed, 62 insertions(+)
> >>>   create mode 100644 xen/arch/arm/arm64/vgic-v3-sr.c
> >>>
> >>> diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c
b/xen/arch/arm/arm64/vgic-v3-sr.c
> >>> new file mode 100644
> >>> index 00..39ab1ed6ca
> >>> --- /dev/null
> >>> +++ b/xen/arch/arm/arm64/vgic-v3-sr.c
> >>> @@ -0,0 +1,60 @@
> >>> +/*
> >>> + * xen/arch/arm/arm64/vgic-v3-sr.c
> >>> + *
> >>> + * Code to emulate group0/group1 traps for handling
> >>> + * cavium erratum 30115
> >>> + *
> >>> + * Manish Jaggi <manish.ja...@cavium.com
<mailto:manish.ja...@cavium.com>>
> >>> + * Copyright (c) 2018 Cavium.
> >> IANAL, but I don't think this copyright notice is correct.
> >>
> >> I wrote about 90% of this series, and the copyright for that
    code is
> >> owned by ARM, and licensed under the GPLv2. You have the right to
> >> duplicate that code and do almost whatever you want with
(within the
> >> limits of the GPLv2), but you still don't own the copyright.
> >>
> >> I suggest you get in touch with your legal department for
clarification
> >> on the matter.
> > I will remove the copyright line, and add this
> > Original Author: Marc Zyngier <>
> > Ported to Xen by: Manish Jaggi <>
>
> You're missing the point. I don't give a damn about the
authorship (I'm
> not exactly proud to have written that code).

:-D

> The problem at hand is the
> ARM copyright, which should be preserved (as no-one in Cavium
wrote a
> single line of the original code).

I have been asking myself similar questions for a while now when we
import code from Linux. The copyright/author line at the top of
the file
is somewhat arbitrary as every person that touched the code has
copyright over her modifications. This is why at some point I
thought we
had to retain the full list of Signed-off-by lines that ever
touched the
code in question, but then, reading the DCO terms one more time:

 (b) The contribution is based upon previous work that, to the best
     of my knowledge, is covered under an appropriate open source
     license and I have the right under that license to submit that
     work with modifications, whether created in whole or in part
     by me, under the same open source license (unless I am
     permitted to submit under a different license), as indicated
     in the file; or

I checked in the Linux kernel when code was imported from the Xen
hypervisor to KVM a long time ago, and only a singled Signed-off-by of
the person importing the code was used.


It does not mean it was a good practice ;).


This is how I came to the conclusion that actually we don't need to do
anything special, although it would be nice as a courtesy to
retain the
copyright/author lines at the top of the file. It would also be
nice to
have the original Linux commit id in the commit message t

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

On 03/27/2018 04:55 PM, Marc Zyngier wrote:

On 27/03/18 12:15, Manish Jaggi wrote:


On 03/27/2018 04:41 PM, Marc Zyngier wrote:

On 27/03/18 12:07, Manish Jaggi wrote:

On 03/27/2018 04:35 PM, Marc Zyngier wrote:

On 27/03/18 11:56, Manish Jaggi wrote:

On 03/27/2018 04:15 PM, Marc Zyngier wrote:

On 27/03/18 11:35, Manish Jaggi wrote:

On 03/27/2018 04:00 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/arm64/vgic-v3-sr.c | 70 
+
  xen/include/asm-arm/arm64/sysregs.h |  1 +
  xen/include/asm-arm/gic_v3_defs.h   |  6 
  3 files changed, 77 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 39ab1ed6ca..ed4254acf9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -18,10 +18,76 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
  
+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)

+
+static int vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, vgic_v3_get_bpr1(vmcr));
+}
+
+static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_bpr1(struct cpu_user_regs *regs, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_bpr1(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
+}
+
  /*
   * returns true if the register is emulated.
   */
@@ -40,6 +106,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
  
  switch ( hsr.bits & HSR_SYSREG_REGS_MASK )

  {
+case HSR_SYSREG_ICC_BPR1_EL1:
+ vreg_emulate_bpr1(regs, hsr);
+ break;

What is the rational for indirecting through a function and moving the
reading of VMCR to the leaf functions? I appreciate that this doesn't
change much, but since this is a port of existing code, it will make
more complex the port of potential fixes.

I used xen template of handling sysreg traps
If you see the file xen/arch/arm/arm64/sysreg.c
a handle_XXX function is used throughout...

Sure, but this is not sysreg.c. This is a separate file for a reason
(i.e. it is imported code). Anyway, that's for the Xen maintainers to
decide.

More importantly, my other question still stand: most trap functions do
require VMCR as an input. Why moving it to the leaf functions?

Same reason, I was keeping the interface same of all handle_XXX functions
handle_XXX(regs, hsr, ...)

Do you want me to change both to match with your patch or it is ok?

My preference would be to keep the code as initially written, as you're
pointlessly changing the flow. Again, that's for the maintainers to
comment, but you should at the very least indicate that change in the
commit log.

I did in the cover letter

which, crucially, doesn't end-up in the commit. Oh well.

I am working on to address the two points, will send v3 later today.
- will remove emulate functions
- and pass vmcr as a param.

Will it be possible to review the remaining part of the code, so that I
can address
other comments in v3 as well.

I suggest you wait until some other folks have a chance to properly
review the series. You only posted the stuff this morning, give them a
chance. A week between two versions is probably the right timing.

Xen 4.11 window closes this week, so I have only few days.
I am hoping to get your ack before that.

   

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

On 03/27/2018 04:41 PM, Marc Zyngier wrote:

On 27/03/18 12:07, Manish Jaggi wrote:


On 03/27/2018 04:35 PM, Marc Zyngier wrote:

On 27/03/18 11:56, Manish Jaggi wrote:

On 03/27/2018 04:15 PM, Marc Zyngier wrote:

On 27/03/18 11:35, Manish Jaggi wrote:

On 03/27/2018 04:00 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 70 
+
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 xen/include/asm-arm/gic_v3_defs.h   |  6 
 3 files changed, 77 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 39ab1ed6ca..ed4254acf9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -18,10 +18,76 @@
  */
 
 #include 

+#include 
 #include 
 #include 
 #include 
 
+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)

+
+static int vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, vgic_v3_get_bpr1(vmcr));
+}
+
+static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_bpr1(struct cpu_user_regs *regs, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_bpr1(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
+}
+
 /*
  * returns true if the register is emulated.
  */
@@ -40,6 +106,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
 
 switch ( hsr.bits & HSR_SYSREG_REGS_MASK )

 {
+case HSR_SYSREG_ICC_BPR1_EL1:
+ vreg_emulate_bpr1(regs, hsr);
+ break;

What is the rational for indirecting through a function and moving the
reading of VMCR to the leaf functions? I appreciate that this doesn't
change much, but since this is a port of existing code, it will make
more complex the port of potential fixes.

I used xen template of handling sysreg traps
If you see the file xen/arch/arm/arm64/sysreg.c
a handle_XXX function is used throughout...

Sure, but this is not sysreg.c. This is a separate file for a reason
(i.e. it is imported code). Anyway, that's for the Xen maintainers to
decide.

More importantly, my other question still stand: most trap functions do
require VMCR as an input. Why moving it to the leaf functions?

Same reason, I was keeping the interface same of all handle_XXX functions
handle_XXX(regs, hsr, ...)

Do you want me to change both to match with your patch or it is ok?

My preference would be to keep the code as initially written, as you're
pointlessly changing the flow. Again, that's for the maintainers to
comment, but you should at the very least indicate that change in the
commit log.

I did in the cover letter

which, crucially, doesn't end-up in the commit. Oh well.

I am working on to address the two points, will send v3 later today.
- will remove emulate functions
- and pass vmcr as a param.

Will it be possible to review the remaining part of the code, so that I 
can address

other comments in v3 as well.

Thanks,
Manish


M.



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

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

On 03/27/2018 04:35 PM, Marc Zyngier wrote:

On 27/03/18 11:56, Manish Jaggi wrote:


On 03/27/2018 04:15 PM, Marc Zyngier wrote:

On 27/03/18 11:35, Manish Jaggi wrote:

On 03/27/2018 04:00 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
xen/arch/arm/arm64/vgic-v3-sr.c | 70 
+
xen/include/asm-arm/arm64/sysregs.h |  1 +
xen/include/asm-arm/gic_v3_defs.h   |  6 
3 files changed, 77 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 39ab1ed6ca..ed4254acf9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -18,10 +18,76 @@
 */

#include 

+#include 
#include 
#include 
#include 

+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)

+
+static int vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, vgic_v3_get_bpr1(vmcr));
+}
+
+static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_bpr1(struct cpu_user_regs *regs, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_bpr1(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
+}
+
/*
 * returns true if the register is emulated.
 */
@@ -40,6 +106,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)

switch ( hsr.bits & HSR_SYSREG_REGS_MASK )

{
+case HSR_SYSREG_ICC_BPR1_EL1:
+ vreg_emulate_bpr1(regs, hsr);
+ break;

What is the rational for indirecting through a function and moving the
reading of VMCR to the leaf functions? I appreciate that this doesn't
change much, but since this is a port of existing code, it will make
more complex the port of potential fixes.

I used xen template of handling sysreg traps
If you see the file xen/arch/arm/arm64/sysreg.c
a handle_XXX function is used throughout...

Sure, but this is not sysreg.c. This is a separate file for a reason
(i.e. it is imported code). Anyway, that's for the Xen maintainers to
decide.

More importantly, my other question still stand: most trap functions do
require VMCR as an input. Why moving it to the leaf functions?

Same reason, I was keeping the interface same of all handle_XXX functions
handle_XXX(regs, hsr, ...)

Do you want me to change both to match with your patch or it is ok?

My preference would be to keep the code as initially written, as you're
pointlessly changing the flow. Again, that's for the maintainers to
comment, but you should at the very least indicate that change in the
commit log.

I did in the cover letter

few changes are made:
...

- vreg_emulate_XXX functions are defined for emulating g0/g1 registers,
  basically these functions wrap calling of read/write functions based on
  isread in a separate function.

- read/write_gicreg is replaced by READ/WRITE_SYSREG32 which is already
  present in xen code.


M.



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

Re: [Xen-devel] [PATCH v2 09/17] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

[Manish Jaggi]

On 03/27/2018 04:26 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported from linux to xen
commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e
(KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler)

Add a handler for reading the guest's view of the ICV_HPPIR1_EL1
register. This is a simple parsing of the available LRs, extracting the
highest available interrupt.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/arm64/vgic-v3-sr.c | 31 +++
  xen/include/asm-arm/arm64/sysregs.h |  1 +
  2 files changed, 32 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index c67e7c6ada..f11c7646da 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -674,6 +674,33 @@ static void vreg_emulate_apxr3(struct cpu_user_regs *regs,
  vgic_v3_write_apxrn(regs, hsr, 3);
  }
  
+static void vgic_v3_read_hppir1(struct cpu_user_regs *regs,

+const union hsr hsr)
+{
+uint64_t lr_val;
+int lr, lr_grp, grp;
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+grp = vgic_v3_get_group(hsr);
+lr = vgic_v3_highest_priority_lr(regs, vmcr, _val);
+
+if ( lr == -1 )
+goto spurious;
+
+lr_grp = !!(lr_val & ICH_LR_GROUP);
+if ( lr_grp != grp )
+lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+spurious:
+set_user_reg(regs, hsr.sysreg.reg, lr_val & ICH_LR_VIRTUAL_ID_MASK);
+}
+
+static void vreg_emulate_hppir1(struct cpu_user_regs *regs,
+const union hsr hsr)
+{
+vgic_v3_read_hppir1(regs, hsr);
+}

See why I said that this "emulate" function idea didn't hold much water?
I wanted to put a check for read call, but I was just trying to match 
the patch,
So that a later patch would inject an undef exception to guest if a 
write is issue by guest on hppir1


M.



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

Re: [Xen-devel] [PATCH v2 12/17] arm64: vgic-v3: Add misc Group-0 handlers

[Manish Jaggi]

On 03/27/2018 04:28 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit:
eab0b2dc4f6f34147e3d10da49ab8032e15dbea0
(KVM: arm64: vgic-v3: Add misc Group-0 handlers)

A number of Group-0 registers can be handled by the same accessors
as that of Group-1, so let's add the required system register encodings
and catch them in the dispatching function.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/arm64/vgic-v3-sr.c | 7 +++
  xen/include/asm-arm/arm64/sysregs.h | 4 
  2 files changed, 11 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index d854b1070d..201194c713 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -793,30 +793,37 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
  vreg_emulate_igrpen1(regs, hsr);
  break;
  
+case HSR_SYSREG_ICC_IAR0_EL1:

  case HSR_SYSREG_ICC_IAR1_EL1:
  vreg_emulate_iar(regs, hsr);
  break;
  
+case HSR_SYSREG_ICC_EOIR0_EL1:

  case HSR_SYSREG_ICC_EOIR1_EL1:
  vreg_emulate_eoi(regs, hsr);
  break;
  
+case HSR_SYSREG_ICC_AP0Rn_EL1(0):

  case HSR_SYSREG_ICC_AP1Rn_EL1(0):
  vreg_emulate_apxr0(regs, hsr);
  break;
  
+case HSR_SYSREG_ICC_AP0Rn_EL1(1):

  case HSR_SYSREG_ICC_AP1Rn_EL1(1):
  vreg_emulate_apxr1(regs, hsr);
  break;
  
+case HSR_SYSREG_ICC_AP0Rn_EL1(2):

  case HSR_SYSREG_ICC_AP1Rn_EL1(2):
  vreg_emulate_apxr2(regs, hsr);
  break;
  
+case HSR_SYSREG_ICC_AP0Rn_EL1(3):

  case HSR_SYSREG_ICC_AP1Rn_EL1(3):
  vreg_emulate_apxr3(regs, hsr);
  break;
  
+case HSR_SYSREG_ICC_HPPIR0_EL1:

  case HSR_SYSREG_ICC_HPPIR1_EL1:
  vreg_emulate_hppir1(regs, hsr);

This doesn't shock you a tiny bit?

Ah, it should be vgic_emulate_hppir.

M.



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

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

On 03/27/2018 04:15 PM, Marc Zyngier wrote:

On 27/03/18 11:35, Manish Jaggi wrote:


On 03/27/2018 04:00 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
   xen/arch/arm/arm64/vgic-v3-sr.c | 70 
+
   xen/include/asm-arm/arm64/sysregs.h |  1 +
   xen/include/asm-arm/gic_v3_defs.h   |  6 
   3 files changed, 77 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 39ab1ed6ca..ed4254acf9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -18,10 +18,76 @@
*/
   
   #include 

+#include 
   #include 
   #include 
   #include 
   
+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)

+
+static int vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, vgic_v3_get_bpr1(vmcr));
+}
+
+static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_bpr1(struct cpu_user_regs *regs, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_bpr1(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
+}
+
   /*
* returns true if the register is emulated.
*/
@@ -40,6 +106,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
   
   switch ( hsr.bits & HSR_SYSREG_REGS_MASK )

   {
+case HSR_SYSREG_ICC_BPR1_EL1:
+ vreg_emulate_bpr1(regs, hsr);
+ break;

What is the rational for indirecting through a function and moving the
reading of VMCR to the leaf functions? I appreciate that this doesn't
change much, but since this is a port of existing code, it will make
more complex the port of potential fixes.

I used xen template of handling sysreg traps
If you see the file xen/arch/arm/arm64/sysreg.c
a handle_XXX function is used throughout...

Sure, but this is not sysreg.c. This is a separate file for a reason
(i.e. it is imported code). Anyway, that's for the Xen maintainers to
decide.

More importantly, my other question still stand: most trap functions do
require VMCR as an input. Why moving it to the leaf functions?

Same reason, I was keeping the interface same of all handle_XXX functions
handle_XXX(regs, hsr, ...)

Do you want me to change both to match with your patch or it is ok?


Thanks,

M.



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

Re: [Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

On 03/27/2018 04:00 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/arm64/vgic-v3-sr.c | 70 +
  xen/include/asm-arm/arm64/sysregs.h |  1 +
  xen/include/asm-arm/gic_v3_defs.h   |  6 
  3 files changed, 77 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 39ab1ed6ca..ed4254acf9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -18,10 +18,76 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
  
+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)

+
+static int vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, vgic_v3_get_bpr1(vmcr));
+}
+
+static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_bpr1(struct cpu_user_regs *regs, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_bpr1(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
+}
+
  /*
   * returns true if the register is emulated.
   */
@@ -40,6 +106,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
  
  switch ( hsr.bits & HSR_SYSREG_REGS_MASK )

  {
+case HSR_SYSREG_ICC_BPR1_EL1:
+ vreg_emulate_bpr1(regs, hsr);
+ break;

What is the rational for indirecting through a function and moving the
reading of VMCR to the leaf functions? I appreciate that this doesn't
change much, but since this is a port of existing code, it will make
more complex the port of potential fixes.

I used xen template of handling sysreg traps
If you see the file xen/arch/arm/arm64/sysreg.c
a handle_XXX function is used throughout...

void do_sysreg(struct cpu_user_regs *regs,
   const union hsr hsr)
{
  ...
    /*
 * MDCR_EL2.TDRA
 *
 * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
 */
    case HSR_SYSREG_MDRAR_EL1:
    return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 1);


This comment applies throughout the series.

Thanks,

M.



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

Re: [Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

[Manish Jaggi]

On 03/27/2018 03:31 PM, Marc Zyngier wrote:

On 27/03/18 10:07, Manish Jaggi wrote:

The errata will require to emulate the GIC virtual CPU interface in Xen.
Because the hypervisor will update its internal state of the vGIC, we want
to avoid messing up with it. So the errata is handled separately from the
rest of the hypervisor.

New file vgic-v3-sr.c is added which will hold trap and emulate code
for group0 / group1 registers. Workaround for cavium Errata 30115
needs this emulation code.

vgic_v3_handle_cpuif_access would be called from do_trap_guest_sync
in subsequent patches based on errata macros.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/arm64/vgic-v3-sr.c   | 60 +++
  xen/include/asm-arm/arm64/traps.h |  2 ++
  2 files changed, 62 insertions(+)
  create mode 100644 xen/arch/arm/arm64/vgic-v3-sr.c

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
new file mode 100644
index 00..39ab1ed6ca
--- /dev/null
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -0,0 +1,60 @@
+/*
+ * xen/arch/arm/arm64/vgic-v3-sr.c
+ *
+ * Code to emulate group0/group1 traps for handling
+ * cavium erratum 30115
+ *
+ * Manish Jaggi <manish.ja...@cavium.com>
+ * Copyright (c) 2018 Cavium.

IANAL, but I don't think this copyright notice is correct.

I wrote about 90% of this series, and the copyright for that code is
owned by ARM, and licensed under the GPLv2. You have the right to
duplicate that code and do almost whatever you want with (within the
limits of the GPLv2), but you still don't own the copyright.

I suggest you get in touch with your legal department for clarification
on the matter.

I will remove the copyright line, and add this
Original Author: Marc Zyngier <>
Ported to Xen by: Manish Jaggi <>

Hope that is fine.
I can resend this single patch

Thanks,

M.



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

[Xen-devel] [PATCH v2 17/17] arm64: if trapping a read-from-write-only GICv3 access inject undef exception in guest

[Manish Jaggi]

This patch is ported to xen from linux commit:
e7f1d1eef482150a64a6e6ad8faf40f8f97eed67
KVM: arm64: Log an error if trapping a read-from-write-only GICv3 access

A read-from-write-only GICv3 access should UNDEF at EL1. But since
we're in complete paranoia-land with broken CPUs, let's assume the
worse and gracefully handle the case.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 14276a4c92..d5dc8168c8 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -614,7 +614,11 @@ static void vgic_v3_write_eoir(struct cpu_user_regs *regs,
 
 static void vreg_emulate_eoi(struct cpu_user_regs *regs, const union hsr hsr)
 {
-vgic_v3_write_eoir(regs, hsr);
+
+if ( unlikely(hsr.sysreg.read) )
+inject_undef_exception(regs, hsr);
+else
+vgic_v3_write_eoir(regs, hsr);
 }
 
 static void vgic_v3_read_apxrn(struct cpu_user_regs *regs,
-- 
2.14.1


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

[Xen-devel] [PATCH v2 14/17] arm64: Add config for Cavium Thunder erratum 30115

[Manish Jaggi]

Some Cavium Thunder CPUs suffer a problem where a Xen guest may
inadvertently cause the host kernel to quit receiving interrupts.
This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will
provide workaround.

This patch is ported to xen from linux kernel commit:
690a341577f9adf2c275ababe0dcefe91898bbf0
arm64: Add workaround for Cavium Thunder erratum 30115

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 docs/misc/arm/silicon-errata.txt |  1 +
 xen/arch/arm/Kconfig | 11 +++
 xen/arch/arm/cpuerrata.c | 21 +
 xen/include/asm-arm/cpuerrata.h  |  1 +
 xen/include/asm-arm/cpufeature.h |  3 ++-
 5 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index c9854c39f4..a2546d4bb5 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -48,3 +48,4 @@ stable hypervisors.
 | ARM| Cortex-A57  | #852523 | N/A 
|
 | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
 | ARM| Cortex-A57  | #834220 | ARM64_ERRATUM_834220
|
+| CAVIUM | ThunderX1   | #30115  | CAVIUM_ERRATUM_30115
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index f58019d6ed..762b761f7d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -169,6 +169,17 @@ config ARM64_ERRATUM_834220
 
  If unsure, say Y.
 
+config CAVIUM_ERRATUM_30115
+   bool "Cavium Erratum 30115"
+   depends on HAS_GICV3
+   help
+ On ThunderX T88 pass 1.x through 2.2, T81 pass 1.0 through
+ 1.2, and T83 Pass 1.0, guest execution may disable
+ interrupts in host. Trapping both GICv3 group-0 and group-1
+ accesses sidesteps the issue.
+
+ If unsure, say Y.
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index fe9e9facbe..d49698f785 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -56,6 +56,27 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
(1 << MIDR_VARIANT_SHIFT) | 2),
 },
+#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+{
+/* Cavium ThunderX, T88 pass 1.x - 2.2 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+{
+/* Cavium ThunderX, T81 pass 1.0 - 1.2 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x02),
+},
+{
+/* Cavium ThunderX, T83 pass 1.0 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX_83XX, 0x00, 0x00),
+},
 #endif
 {},
 };
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 8b158429c7..eff606c422 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -41,6 +41,7 @@ static inline bool check_workaround_##erratum(void)   
  \
 
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
 CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(cavium_30115, ARM64_WORKAROUND_CAVIUM_30115, 
CONFIG_ARM_64)
 
 #undef CHECK_WORKAROUND_HELPER
 
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index f00b6dbd39..d409636bf0 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -42,8 +42,9 @@
 #define LIVEPATCH_FEATURE   4
 #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
 #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
+#define ARM64_WORKAROUND_CAVIUM_30115 7
 
-#define ARM_NCAPS   7
+#define ARM_NCAPS   8
 
 #ifndef __ASSEMBLY__
 
-- 
2.14.1


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

[Xen-devel] [PATCH v2 08/17] arm64: vgic-v3: Add ICV_AP1Rn_EL1 handler

[Manish Jaggi]

This patch is a xen port of linux commit
f9e7449c780f688bf61a13dfa8c344afeb4ad6e0
KVM: arm64: vgic-v3: Add ICV_AP1Rn_EL1 handler

Add a handler for reading/writing the guest's view of the ICV_AP1Rn_EL1
registers. We just map them to the corresponding ICH_AP1Rn_EL2
registers.

This patch calls vreg_emulate_apxrN which has a if (hsr.sysreg.read)
and based on that calls read and write functions. This code placement
is slight different from linux code, which calls read/write functions
from within switch case.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 76 +
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 2 files changed, 77 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index e32ec01f56..c67e7c6ada 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -614,6 +614,66 @@ static void vreg_emulate_eoi(struct cpu_user_regs *regs, 
const union hsr hsr)
 vgic_v3_write_eoir(regs, hsr);
 }
 
+static void vgic_v3_read_apxrn(struct cpu_user_regs *regs,
+   const union hsr hsr, int n)
+{
+uint32_t val;
+
+if ( !vgic_v3_get_group(hsr) )
+val = vgic_v3_read_ap0rn(n);
+else
+val = vgic_v3_read_ap1rn(n);
+
+   set_user_reg(regs, hsr.sysreg.reg, val);
+}
+
+static void vgic_v3_write_apxrn(struct cpu_user_regs *regs,
+const union hsr hsr, int n)
+{
+uint32_t val = get_user_reg(regs, hsr.sysreg.reg);
+
+if ( !vgic_v3_get_group(hsr) )
+vgic_v3_write_ap0rn(val, n);
+else
+vgic_v3_write_ap1rn(val, n);
+}
+
+static void vreg_emulate_apxr0(struct cpu_user_regs *regs,
+   const union hsr hsr)
+{
+if( hsr.sysreg.read )
+vgic_v3_read_apxrn(regs, hsr, 0);
+else
+vgic_v3_write_apxrn(regs, hsr, 0);
+}
+
+static void vreg_emulate_apxr1(struct cpu_user_regs *regs,
+   const union hsr hsr)
+{
+if( hsr.sysreg.read )
+vgic_v3_read_apxrn(regs, hsr, 1);
+else
+vgic_v3_write_apxrn(regs, hsr, 1);
+}
+
+static void vreg_emulate_apxr2(struct cpu_user_regs *regs,
+   const union hsr hsr)
+{
+if( hsr.sysreg.read )
+vgic_v3_read_apxrn(regs, hsr, 2);
+else
+vgic_v3_write_apxrn(regs, hsr, 2);
+}
+
+static void vreg_emulate_apxr3(struct cpu_user_regs *regs,
+   const union hsr hsr)
+{
+if( hsr.sysreg.read )
+vgic_v3_read_apxrn(regs, hsr, 3);
+else
+vgic_v3_write_apxrn(regs, hsr, 3);
+}
+
 /*
  * returns true if the register is emulated.
  */
@@ -648,6 +708,22 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 vreg_emulate_eoi(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_AP1Rn_EL1(0):
+vreg_emulate_apxr0(regs, hsr);
+break;
+
+case HSR_SYSREG_ICC_AP1Rn_EL1(1):
+vreg_emulate_apxr1(regs, hsr);
+break;
+
+case HSR_SYSREG_ICC_AP1Rn_EL1(2):
+vreg_emulate_apxr2(regs, hsr);
+break;
+
+case HSR_SYSREG_ICC_AP1Rn_EL1(3):
+vreg_emulate_apxr3(regs, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index f9110ebf9c..f3cc9ff7b5 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -85,6 +85,7 @@
 #define HSR_SYSREG_PMINTENCLR_EL1 HSR_SYSREG(3,0,c9,c14,2)
 #define HSR_SYSREG_MAIR_EL1   HSR_SYSREG(3,0,c10,c2,0)
 #define HSR_SYSREG_AMAIR_EL1  HSR_SYSREG(3,0,c10,c3,0)
+#define HSR_SYSREG_ICC_AP1Rn_EL1(n) HSR_SYSREG(3,0,c12,c9, n)
 #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
 #define HSR_SYSREG_ICC_ASGI1R_EL1 HSR_SYSREG(3,1,c12,c11,6)
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
-- 
2.14.1


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

[Xen-devel] [PATCH v2 09/17] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

[Manish Jaggi]

This patch is ported from linux to xen
commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e
(KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler)

Add a handler for reading the guest's view of the ICV_HPPIR1_EL1
register. This is a simple parsing of the available LRs, extracting the
highest available interrupt.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 31 +++
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 2 files changed, 32 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index c67e7c6ada..f11c7646da 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -674,6 +674,33 @@ static void vreg_emulate_apxr3(struct cpu_user_regs *regs,
 vgic_v3_write_apxrn(regs, hsr, 3);
 }
 
+static void vgic_v3_read_hppir1(struct cpu_user_regs *regs,
+const union hsr hsr)
+{
+uint64_t lr_val;
+int lr, lr_grp, grp;
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+grp = vgic_v3_get_group(hsr);
+lr = vgic_v3_highest_priority_lr(regs, vmcr, _val);
+
+if ( lr == -1 )
+goto spurious;
+
+lr_grp = !!(lr_val & ICH_LR_GROUP);
+if ( lr_grp != grp )
+lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+spurious:
+set_user_reg(regs, hsr.sysreg.reg, lr_val & ICH_LR_VIRTUAL_ID_MASK);
+}
+
+static void vreg_emulate_hppir1(struct cpu_user_regs *regs,
+const union hsr hsr)
+{
+vgic_v3_read_hppir1(regs, hsr);
+}
+
 /*
  * returns true if the register is emulated.
  */
@@ -724,6 +751,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 vreg_emulate_apxr3(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_HPPIR1_EL1:
+vreg_emulate_hppir1(regs, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index f3cc9ff7b5..8a6345c2d2 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -94,6 +94,7 @@
 #define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
+#define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH v2 16/17] arm64: if trapping a write-to-read-only GICv3 access inject Undef exception in guest

[Manish Jaggi]

This patch is a port to xen from linux commit:
7b1dba1f7325629427c0e5bdf014159b229d16c8
KVM: arm64: Log an error if trapping a write-to-read-only GICv3 access

A write-to-read-only GICv3 access should UNDEF at EL1. But since
we're in complete paranoia-land with broken CPUs, let's assume the
worse and gracefully handle the case.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 201194c713..14276a4c92 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -480,7 +480,10 @@ spurious:
 
 static void vreg_emulate_iar(struct cpu_user_regs *regs, const union hsr hsr)
 {
-vgic_v3_read_iar(regs, hsr);
+if ( unlikely(!hsr.sysreg.read) )
+inject_undef_exception(regs, hsr);
+else
+vgic_v3_read_iar(regs, hsr);
 }
 
 static int vgic_v3_find_active_lr(int intid, uint64_t *lr_val)
@@ -698,7 +701,10 @@ spurious:
 static void vreg_emulate_hppir1(struct cpu_user_regs *regs,
 const union hsr hsr)
 {
-vgic_v3_read_hppir1(regs, hsr);
+if ( unlikely(!hsr.sysreg.read) )
+inject_undef_exception(regs, hsr);
+else
+vgic_v3_read_hppir1(regs, hsr);
 }
 
 static void vgic_v3_read_bpr0(struct cpu_user_regs *regs, int regidx)
-- 
2.14.1


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

[Xen-devel] [PATCH v2 12/17] arm64: vgic-v3: Add misc Group-0 handlers

[Manish Jaggi]

This patch is ported to xen from linux commit:
eab0b2dc4f6f34147e3d10da49ab8032e15dbea0
(KVM: arm64: vgic-v3: Add misc Group-0 handlers)

A number of Group-0 registers can be handled by the same accessors
as that of Group-1, so let's add the required system register encodings
and catch them in the dispatching function.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 7 +++
 xen/include/asm-arm/arm64/sysregs.h | 4 
 2 files changed, 11 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index d854b1070d..201194c713 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -793,30 +793,37 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 vreg_emulate_igrpen1(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_IAR0_EL1:
 case HSR_SYSREG_ICC_IAR1_EL1:
 vreg_emulate_iar(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_EOIR0_EL1:
 case HSR_SYSREG_ICC_EOIR1_EL1:
 vreg_emulate_eoi(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(0):
 case HSR_SYSREG_ICC_AP1Rn_EL1(0):
 vreg_emulate_apxr0(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(1):
 case HSR_SYSREG_ICC_AP1Rn_EL1(1):
 vreg_emulate_apxr1(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(2):
 case HSR_SYSREG_ICC_AP1Rn_EL1(2):
 vreg_emulate_apxr2(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(3):
 case HSR_SYSREG_ICC_AP1Rn_EL1(3):
 vreg_emulate_apxr3(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_HPPIR0_EL1:
 case HSR_SYSREG_ICC_HPPIR1_EL1:
 vreg_emulate_hppir1(regs, hsr);
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 8a4f5b45cb..6d346d84db 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -97,6 +97,10 @@
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
 #define HSR_SYSREG_ICC_BPR0_EL1   HSR_SYSREG(3,0,c12,c8,3)
 #define HSR_SYSREG_ICC_IGRPEN0_EL1 HSR_SYSREG(3,0,c12,c12,6)
+#define HSR_SYSREG_ICC_IAR0_EL1   HSR_SYSREG(3,0,c12,c8,0)
+#define HSR_SYSREG_ICC_EOIR0_EL1  HSR_SYSREG(3,0,c12,c8,1)
+#define HSR_SYSREG_ICC_HPPIR0_EL1 HSR_SYSREG(3,0,c12,c8,2)
+#define HSR_SYSREG_ICC_AP0Rn_EL1(n) HSR_SYSREG(3,0,c12,c8,4|n)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH v2 13/17] arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family

[Manish Jaggi]

Add MIDR values for Cavium ThunderX1 SoC family: ThunderX1, 81XX, 83XX.

This patch copies the below defines as is from linux kernel code.
arch/arm64/include/asm/cputype.h

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/include/asm-arm/processor.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 65eb1071e1..62ad244785 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -43,15 +43,24 @@
 })
 
 #define ARM_CPU_IMP_ARM 0x41
+#define ARM_CPU_IMP_CAVIUM  0x43
 
 #define ARM_CPU_PART_CORTEX_A15 0xC0F
 #define ARM_CPU_PART_CORTEX_A53 0xD03
 #define ARM_CPU_PART_CORTEX_A57 0xD07
 
+#define CAVIUM_CPU_PART_THUNDERX  0x0A1
+#define CAVIUM_CPU_PART_THUNDERX_81XX 0x0A2
+#define CAVIUM_CPU_PART_THUNDERX_83XX 0x0A3
+
 #define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
 
+#define MIDR_THUNDERX  MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX)
+#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_83XX)
+
 /* MPIDR Multiprocessor Affinity Register */
 #define _MPIDR_UP   (30)
 #define MPIDR_UP(_AC(1,U) << _MPIDR_UP)
-- 
2.14.1


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

[Xen-devel] [PATCH v2 15/17] arm: Hook workaround handler from traps.c based on Cavium workaround_30115

[Manish Jaggi]

Function vgic_v3_handle_cpuif_access is called from do_trap_guest_sync
if ARM64_WORKAROUND_CAVIUM_30115 capability is found.

A flag skip_hyp_tail is introduced in struct cpu_info. This flag
is used to skip leave_hypervisor_tail when enter_hypervisor_head
is not invoked. enter_hypervisor_head andleave_hypervisor_tail are
invoked in sync, if one is not called other one should be skipped,
otherwise guest vGIC state be out-of-date.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/Makefile   |  1 +
 xen/arch/arm/traps.c  | 31 +++
 xen/include/asm-arm/current.h |  3 ++-
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 718fe44455..eed3c9e913 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -11,3 +11,4 @@ obj-y += smpboot.o
 obj-y += traps.o
 obj-y += vfp.o
 obj-y += vsysreg.o
+obj-$(CONFIG_CAVIUM_ERRATUM_30115) += vgic-v3-sr.o
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..1dc34275b3 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2103,6 +2103,27 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 {
 const union hsr hsr = { .bits = regs->hsr };
 
+if ( check_workaround_cavium_30115() )
+{
+if ( vgic_v3_handle_cpuif_access(regs) )
+{
+   /*
+* if true, g0/g1 vgic register trap is emulated for errata
+* so rest of handling of do_trap_guest_sync is not required.
+*/
+advance_pc(regs, hsr);
+/*
+ * enter_hypervisor_head is not invoked when workaround 30115
+ * is in place. enter_hypervisor_head and leave_hypervisor_tail
+ * are invoked in sync, if one is not called other one should be
+ * skipped, otherwise guest vGIC state be out-of-date.
+ */
+get_cpu_info()->skip_hyp_tail = true;
+
+return;
+}
+}
+
 enter_hypervisor_head(regs);
 
 switch (hsr.ec) {
@@ -2295,6 +2316,16 @@ void do_trap_fiq(struct cpu_user_regs *regs)
 
 void leave_hypervisor_tail(void)
 {
+/*
+ * if skip_hyp_tail is set simply retrun;
+ */
+if ( unlikely(get_cpu_info()->skip_hyp_tail) )
+{
+/* clear it, so that it is false when not handling g0/g1 traps */
+get_cpu_info()->skip_hyp_tail = false;
+return;
+}
+
 while (1)
 {
 local_irq_disable();
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 7a0971fdea..63b7e68f0b 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -21,7 +21,14 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
 struct cpu_info {
 struct cpu_user_regs guest_cpu_user_regs;
 unsigned long elr;
-unsigned int pad;
+/*
+ * Flag is used to skip leave_hypervisor_tail when enter_hypervisor_head
+ * is not invoked. enter_hypervisor_head andleave_hypervisor_tail are
+ * invoked in sync, if one is not called other one should be skipped,
+ * otherwise guest vGIC state be out-of-date.
+ */
+bool skip_hyp_tail:1;
+unsigned int pad:31;
 };
 
 static inline struct cpu_info *get_cpu_info(void)
-- 
2.14.1


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

[Xen-devel] [PATCH v2 10/17] arm64: vgic-v3: Add ICV_BPR0_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
423de85a98c2b50715a0784a74f6124fbc0b1548
(KVM: arm64: vgic-v3: Add ICV_BPR0_EL1 handler)

Add a handler for reading/writing the guest's view of the ICC_BPR0_EL1
register, which is located in the ICH_VMCR_EL2.BPR0 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 41 +
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 2 files changed, 42 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index f11c7646da..b938e795a8 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -701,6 +701,43 @@ static void vreg_emulate_hppir1(struct cpu_user_regs *regs,
 vgic_v3_read_hppir1(regs, hsr);
 }
 
+static void vgic_v3_read_bpr0(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, vgic_v3_get_bpr0(vmcr));
+}
+
+static void vgic_v3_write_bpr0(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR0_SHIFT;
+val &= ICH_VMCR_BPR0_MASK;
+vmcr &= ~ICH_VMCR_BPR0_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_bpr0(struct cpu_user_regs *regs,
+  const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_bpr0(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_bpr0(regs, hsr.sysreg.reg);
+}
+
 /*
  * returns true if the register is emulated.
  */
@@ -755,6 +792,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 vreg_emulate_hppir1(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_BPR0_EL1:
+vreg_emulate_bpr0(regs, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 8a6345c2d2..55e8185f6a 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -95,6 +95,7 @@
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
+#define HSR_SYSREG_ICC_BPR0_EL1   HSR_SYSREG(3,0,c12,c8,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH v2 11/17] arm64: vgic-v3: Add ICV_IGRPEN0_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
fbc48a0011deb3d51cb657ca9c0f9083f41c0665
(KVM: arm64: vgic-v3: Add ICV_IGNREN0_EL1 handler)

Add a handler for reading/writing the guest's view of the
ICC_IGRPEN0_EL1 register, which is located in the ICH_VMCR_EL2.VENG0
field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 33 +
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 2 files changed, 34 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index b938e795a8..d854b1070d 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -738,6 +738,35 @@ static void vreg_emulate_bpr0(struct cpu_user_regs *regs,
 vgic_v3_write_bpr0(regs, hsr.sysreg.reg);
 }
 
+static void vgic_v3_read_igrpen0(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, !!(vmcr & ICH_VMCR_ENG0_MASK));
+}
+
+static void vgic_v3_write_igrpen0(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( val & 1 )
+vmcr |= ICH_VMCR_ENG0_MASK;
+else
+vmcr &= ~ICH_VMCR_ENG0_MASK;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_igrpen0(struct cpu_user_regs *regs,
+ const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_igrpen0(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_igrpen0(regs, hsr.sysreg.reg);
+}
+
 /*
  * returns true if the register is emulated.
  */
@@ -796,6 +825,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 vreg_emulate_bpr0(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_IGRPEN0_EL1:
+vreg_emulate_igrpen0(regs, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 55e8185f6a..8a4f5b45cb 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -96,6 +96,7 @@
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
 #define HSR_SYSREG_ICC_BPR0_EL1   HSR_SYSREG(3,0,c12,c8,3)
+#define HSR_SYSREG_ICC_IGRPEN0_EL1 HSR_SYSREG(3,0,c12,c12,6)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH v2 03/17] arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
f8b630bc542e0368886ae193d3519c832b270359
KVM: arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

Add a handler for reading/writing the guest's view of ICC_IGRPEN1_EL1
register, which is located in the ICH_VMCR_EL2.VENG1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 32 
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 xen/include/asm-arm/gic_v3_defs.h   |  2 ++
 3 files changed, 35 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index ed4254acf9..edaa13ec1c 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -88,6 +88,34 @@ static void vreg_emulate_bpr1(struct cpu_user_regs *regs, 
const union hsr hsr)
 vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
 }
 
+static void vgic_v3_read_igrpen1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, !!(vmcr & ICH_VMCR_ENG1_MASK));
+}
+
+static void vgic_v3_write_igrpen1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( val & 1 )
+vmcr |= ICH_VMCR_ENG1_MASK;
+else
+vmcr &= ~ICH_VMCR_ENG1_MASK;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_igrpen1(struct cpu_user_regs *regs,
+ const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_igrpen1(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_igrpen1(regs, hsr.sysreg.reg);
+}
 /*
  * returns true if the register is emulated.
  */
@@ -110,6 +138,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
  vreg_emulate_bpr1(regs, hsr);
  break;
 
+case HSR_SYSREG_ICC_IGRPEN1_EL1:
+vreg_emulate_igrpen1(regs, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 025a27b0b4..731cabc74a 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -90,6 +90,7 @@
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
 #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
+#define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 68a34cc353..ff8bda37d1 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -163,6 +163,8 @@
 #define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
 #define ICH_VMCR_BPR1_SHIFT  18
 #define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
+#define ICH_VMCR_ENG1_SHIFT  1
+#define ICH_VMCR_ENG1_MASK   (1 << ICH_VMCR_ENG1_SHIFT)
 
 #define GICH_LR_VIRTUAL_MASK 0x
 #define GICH_LR_VIRTUAL_SHIFT0
-- 
2.14.1


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

[Xen-devel] [PATCH v2 04/17] arm64: Add accessors for the ICH_APxRn_EL2 registers

[Manish Jaggi]

This patch is ported to xen from linux commit
63000dd8006dc987db31ba670edc23142ea91e01
KVM: arm/arm64: vgic-v3: Add accessors for the ICH_APxRn_EL2 registers

As we're about to access the Active Priority registers a lot more,
let's define accessors that take the register number as a parameter.

This patch only has accessors, it does not modify the vgic code.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 93 +
 1 file changed, 93 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index edaa13ec1c..48346ed628 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -116,6 +116,99 @@ static void vreg_emulate_igrpen1(struct cpu_user_regs 
*regs,
 else
 vgic_v3_write_igrpen1(regs, hsr.sysreg.reg);
 }
+
+static void vgic_v3_write_ap0rn(uint32_t val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP0R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP0R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP0R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+static void vgic_v3_write_ap1rn(uint32_t val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP1R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP1R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP1R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+static uint32_t vgic_v3_read_ap0rn(int n)
+{
+uint32_t val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP0R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP0R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP0R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
+static uint32_t vgic_v3_read_ap1rn(int n)
+{
+uint32_t val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP1R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP1R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP1R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
 /*
  * returns true if the register is emulated.
  */
-- 
2.14.1


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

[Xen-devel] [PATCH v2 01/17] arm: Placeholder for handling Group0/1 traps

[Manish Jaggi]

The errata will require to emulate the GIC virtual CPU interface in Xen. 
Because the hypervisor will update its internal state of the vGIC, we want
to avoid messing up with it. So the errata is handled separately from the
rest of the hypervisor.

New file vgic-v3-sr.c is added which will hold trap and emulate code
for group0 / group1 registers. Workaround for cavium Errata 30115
needs this emulation code.

vgic_v3_handle_cpuif_access would be called from do_trap_guest_sync
in subsequent patches based on errata macros.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c   | 60 +++
 xen/include/asm-arm/arm64/traps.h |  2 ++
 2 files changed, 62 insertions(+)
 create mode 100644 xen/arch/arm/arm64/vgic-v3-sr.c

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
new file mode 100644
index 00..39ab1ed6ca
--- /dev/null
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -0,0 +1,60 @@
+/*
+ * xen/arch/arm/arm64/vgic-v3-sr.c
+ *
+ * Code to emulate group0/group1 traps for handling
+ * cavium erratum 30115
+ *
+ * Manish Jaggi <manish.ja...@cavium.com>
+ * Copyright (c) 2018 Cavium.
+ *
+ * Ths program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * returns true if the register is emulated.
+ */
+bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
+{
+bool ret = true;
+const union hsr hsr = { .bits = regs->hsr };
+
+/* Disabling interrupts to prevent change in guest state */
+local_irq_disable();
+if ( hsr.ec != HSR_EC_SYSREG )
+{
+ret = false;
+goto end;
+}
+
+switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
+{
+default:
+ret = false;
+break;
+}
+end:
+local_irq_enable();
+
+return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/traps.h 
b/xen/include/asm-arm/arm64/traps.h
index 2379b578cb..3c3911a69c 100644
--- a/xen/include/asm-arm/arm64/traps.h
+++ b/xen/include/asm-arm/arm64/traps.h
@@ -3,6 +3,8 @@
 
 void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len);
 
+bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs);
+
 void do_sysreg(struct cpu_user_regs *regs,
const union hsr hsr);
 
-- 
2.14.1


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

[Xen-devel] [PATCH v2 07/17] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02
KVM: arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required (EOImode == 0).

Signed-off-by : Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 136 
 xen/include/asm-arm/arm64/sysregs.h |   1 +
 xen/include/asm-arm/gic_v3_defs.h   |   4 ++
 3 files changed, 141 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 026d64506f..e32ec01f56 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -33,6 +33,7 @@
 
 #define ICC_IAR1_EL1_SPURIOUS0x3ff
 #define VGIC_MAX_SPI 1019
+#define VGIC_MIN_LPI 8192
 
 static int vgic_v3_bpr_min(void)
 {
@@ -482,6 +483,137 @@ static void vreg_emulate_iar(struct cpu_user_regs *regs, 
const union hsr hsr)
 vgic_v3_read_iar(regs, hsr);
 }
 
+static int vgic_v3_find_active_lr(int intid, uint64_t *lr_val)
+{
+int i;
+unsigned int used_lrs =  gic_get_num_lrs();
+
+for ( i = 0; i < used_lrs; i++ )
+{
+uint64_t val = gicv3_ich_read_lr(i);
+
+if ( (val & ICH_LR_VIRTUAL_ID_MASK) == intid &&
+(val & ICH_LR_ACTIVE_BIT) )
+{
+*lr_val = val;
+return i;
+}
+}
+
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+return -1;
+}
+
+static int vgic_v3_clear_highest_active_priority(void)
+{
+int i;
+uint32_t hap = 0;
+uint8_t nr_apr_regs = vtr_to_nr_apr_regs(READ_SYSREG32(ICH_VTR_EL2));
+
+for ( i = 0; i < nr_apr_regs; i++ )
+{
+uint32_t ap0, ap1;
+int c0, c1;
+
+ap0 = vgic_v3_read_ap0rn(i);
+ap1 = vgic_v3_read_ap1rn(i);
+if ( !ap0 && !ap1 )
+{
+hap += 32;
+continue;
+}
+
+c0 = ap0 ? __ffs(ap0) : 32;
+c1 = ap1 ? __ffs(ap1) : 32;
+
+/* Always clear the LSB, which is the highest priority */
+if ( c0 < c1 )
+{
+ap0 &= ~BIT(c0);
+vgic_v3_write_ap0rn(ap0, i);
+hap += c0;
+}
+else
+{
+ap1 &= ~BIT(c1);
+vgic_v3_write_ap1rn(ap1, i);
+hap += c1;
+}
+
+/* Rescale to 8 bits of priority */
+return hap << vgic_v3_bpr_min();
+}
+
+return GICV3_IDLE_PRIORITY;
+}
+
+static void vgic_v3_clear_active_lr(int lr, uint64_t lr_val)
+{
+lr_val &= ~ICH_LR_ACTIVE_BIT;
+if ( lr_val & ICH_LR_HW )
+{
+uint32_t pid;
+
+pid = (lr_val & ICH_LR_PHYS_ID_MASK) >> ICH_LR_PHYS_ID_SHIFT;
+WRITE_SYSREG32(pid, ICC_DIR_EL1);
+}
+gicv3_ich_write_lr(lr, lr_val);
+}
+
+static void vgic_v3_bump_eoicount(void)
+{
+uint32_t hcr;
+
+hcr = READ_SYSREG32(ICH_HCR_EL2);
+hcr += 1 << ICH_HCR_EOIcount_SHIFT;
+WRITE_SYSREG32(hcr, ICH_HCR_EL2);
+}
+
+static void vgic_v3_write_eoir(struct cpu_user_regs *regs,
+   const union hsr hsr)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+register_t vid = get_user_reg(regs, hsr.sysreg.reg);
+uint64_t lr_val;
+uint8_t lr_prio, act_prio;
+int lr, grp;
+
+grp = vgic_v3_get_group(hsr);
+
+/* Drop priority in any case */
+act_prio = vgic_v3_clear_highest_active_priority();
+
+/* If EOIing an LPI, no deactivate to be performed */
+if ( vid >= VGIC_MIN_LPI )
+return;
+
+/* EOImode == 1, nothing to be done here */
+if ( vmcr & ICH_VMCR_EOIM_MASK )
+return;
+
+lr = vgic_v3_find_active_lr(vid, _val);
+if ( lr == -1 )
+{
+vgic_v3_bump_eoicount();
+return;
+}
+
+lr_prio = (lr_val & ICH_LR_PRIORITY_MASK) >> ICH_LR_PRIORITY_SHIFT;
+
+/* If priorities or group do not match, the guest has fscked-up. */
+if ( grp != !!(lr_val & ICH_LR_GROUP) ||
+ vgic_v3_pri_to_pre(lr_prio, vmcr, grp) != act_prio )
+return;
+
+/* Let's now perform the deactivation */
+vgic_v3_clear_active_lr(lr, lr_val);
+}
+
+static void vreg_emulate_eoi(struct cpu_user_regs *regs, const union hsr hsr)
+{
+vgic_v3_write_eoir(regs, hsr);
+}
+
 /*
  * returns true if the register is emulated.
  */
@@ -512,6 +644,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs)
 vreg_emulate_iar(regs, hsr);
 break;
 
+case HSR_SYSREG_ICC_EOIR1_EL1:
+vreg_emulate_eoi(regs, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 53d2251840..f9110ebf9c 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -92,6 +92,7 @

[Xen-devel] [PATCH v2 00/17] arm64: Mediate access to GICv3 sysregs at EL2

[Manish Jaggi]

This patchset is based on Marc's patchset below.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1].

As these patches are ported to xen specifically for cavium errata 30115
few changes are made:
- Xen coding style is used

- group1_enable / group0_enable command line options not used.
  CONFIG_CAVIUM_ERRATUM_30115 would enable trapping of group0/1 registers

- check_workaround_cavium_30115 function is used instead to check if emulation
  has to be done.

- Not every patch in [1] is ported to xen, ported are ones which are relevant
  to Cavium Errata 30115.

- vreg_emulate_XXX functions are defined for emulating g0/g1 registers,
  basically these functions wrap calling of read/write functions based on
  isread in a separate function.

- read/write_gicreg is replaced by READ/WRITE_SYSREG32 which is already
  present in xen code.

Most of the trap code is added in vgic-v3-sr.c. Trap handler function is kept
independent of the usual guest trap handling code.

Cavium 30115 Errata Workaround:
  Hypervisor to trap and emulate the following registers:
  Group 0: ICC_IAR0_EL1, ICC_EOIR0_EL1, ICC_HPPIR0_EL1, ICC_BPR0_EL1,
   ICC_AP0R0_EL1, ICC_IGRPEN0_EL1
  Group 1: ICC_IAR1_EL1, ICC_EOIR1_EL1, ICC_HPPIR1_EL1, ICC_BPR1_EL1,
   ICC_AP1R0_EL1, ICC_IGRPEN1_EL1

The errata workaround has been validated on Cavium ThunderX1 platform.
Steps to reproduce the errata
- Boot Xen with 2 cores.
- Disable group1 interrupts in domU kernel
- start domU, the kill and start again.
One of the Xen core would hang.

[1] https://www.spinics.net/lists/arm-kernel/msg587082.html

Changes from v1
- removed __ prefix from function names
- Patches have been realigned to map closely with original patchset

Changes from v0
- Added Group0 traps.
- Some cleanups and documentation

Changes from RFC
- Added commit information on ported patches from linux
- Added skip_hyp_tail to control calling leave_hypervisor_tail 
- Added CAVIUM_CONFIG_ERRATUM_30115 which will auto enable workaround


Manish Jaggi (17):
  arm: Placeholder for handling Group0/1 traps
  arm64: vgic-v3: Add ICV_BPR1_EL1 handler
  arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler
  arm64: Add accessors for the ICH_APxRn_EL2 registers
  Expose ich_read/write_lr in vgic-v3-sr.c
  arm64: Add ICV_IAR1_EL1 handler
  arm64: vgic-v3: Add ICV_EOIR1_EL1 handler
  arm64: vgic-v3: Add ICV_AP1Rn_EL1 handler
  arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler
  arm64: vgic-v3: Add ICV_BPR0_EL1 handler
  arm64: vgic-v3: Add ICV_IGRPEN0_EL1 handler
  arm64: vgic-v3: Add misc Group-0 handlers
  arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family
  arm64: Add config for Cavium Thunder erratum 30115
  arm: Hook workaround handler from traps.c based on Cavium
workaround_30115
  arm64: Inject Undef exception in guest if trapping a
write-to-read-only GICv3 access
  arm64: Inject undef exception in guest if trapping a
read-from-write-only GICv3 access

 docs/misc/arm/silicon-errata.txt|   1 +
 xen/arch/arm/Kconfig|  11 +
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/vgic-v3-sr.c | 866 
 xen/arch/arm/cpuerrata.c|  21 +
 xen/arch/arm/traps.c|  31 ++
 xen/include/asm-arm/arm64/sysregs.h |  12 +
 xen/include/asm-arm/arm64/traps.h   |   2 +
 xen/include/asm-arm/cpuerrata.h |   1 +
 xen/include/asm-arm/cpufeature.h|   3 +-
 xen/include/asm-arm/current.h   |   3 +-
 xen/include/asm-arm/gic_v3_defs.h   |  29 ++
 xen/include/asm-arm/processor.h |   9 +
 13 files changed, 988 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/arm64/vgic-v3-sr.c

-- 
2.14.1


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

[Xen-devel] [PATCH v2 02/17] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
KVM: arm64: vgic-v3: Add ICV_BPR1_EL1 handler

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 70 +
 xen/include/asm-arm/arm64/sysregs.h |  1 +
 xen/include/asm-arm/gic_v3_defs.h   |  6 
 3 files changed, 77 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 39ab1ed6ca..ed4254acf9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -18,10 +18,76 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)
+
+static int vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+set_user_reg(regs, regidx, vgic_v3_get_bpr1(vmcr));
+}
+
+static void vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+static void vreg_emulate_bpr1(struct cpu_user_regs *regs, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+vgic_v3_read_bpr1(regs, hsr.sysreg.reg);
+else
+vgic_v3_write_bpr1(regs, hsr.sysreg.reg);
+}
+
 /*
  * returns true if the register is emulated.
  */
@@ -40,6 +106,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs)
 
 switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
 {
+case HSR_SYSREG_ICC_BPR1_EL1:
+ vreg_emulate_bpr1(regs, hsr);
+ break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 084d2a1e5d..025a27b0b4 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -89,6 +89,7 @@
 #define HSR_SYSREG_ICC_ASGI1R_EL1 HSR_SYSREG(3,1,c12,c11,6)
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
+#define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 65c9dc47cf..68a34cc353 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -157,6 +157,12 @@
 
 #define GICH_VMCR_EOI(1 << 9)
 #define GICH_VMCR_VENG1  (1 << 1)
+#define ICH_VMCR_CBPR_SHIFT  4
+#define ICH_VMCR_CBPR_MASK   (1 << ICH_VMCR_CBPR_SHIFT)
+#define ICH_VMCR_BPR0_SHIFT  21
+#define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
+#define ICH_VMCR_BPR1_SHIFT  18
+#define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
 
 #define GICH_LR_VIRTUAL_MASK 0x
 #define GICH_LR_VIRTUAL_SHIFT0
-- 
2.14.1


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

[Xen-devel] [PATCH v2 06/17] arm64: Add ICV_IAR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
132a324ab62fe4fb8d6dcc2ab4eddb0e93b69afe.
KVM: arm64: vgic-v3: Add ICV_IAR1_EL1 handler

Add a handler for reading the guest's view of the ICC_IAR1_EL1
register. This involves finding the highest priority Group-1
interrupt, checking against both PMR and the active group
priority, activating the interrupt and setting the group
priority as active.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 194 
 xen/include/asm-arm/arm64/sysregs.h |   1 +
 xen/include/asm-arm/gic_v3_defs.h   |  17 
 3 files changed, 212 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index fc5246539e..026d64506f 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -22,8 +22,17 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)
+#define vtr_to_nr_apr_regs(v) (1 << (vtr_to_nr_pre_bits(v) - 5))
+
+#define ESR_ELx_SYS64_ISS_CRM_SHIFT 1
+#define ESR_ELx_SYS64_ISS_CRM_MASK (0xf << ESR_ELx_SYS64_ISS_CRM_SHIFT)
+
+#define ICC_IAR1_EL1_SPURIOUS0x3ff
+#define VGIC_MAX_SPI 1019
 
 static int vgic_v3_bpr_min(void)
 {
@@ -292,6 +301,187 @@ static void gicv3_ich_write_lr(int lr, uint64_t val)
 isb();
 }
 
+static int vgic_v3_get_group(const union hsr hsr)
+{
+uint8_t crm = (hsr.bits & ESR_ELx_SYS64_ISS_CRM_MASK) >>
+  ESR_ELx_SYS64_ISS_CRM_SHIFT;
+
+return crm != 8;
+}
+
+static unsigned int gic_get_num_lrs(void)
+{
+uint32_t vtr;
+
+vtr = READ_SYSREG32(ICH_VTR_EL2);
+return (vtr & GICH_VTR_NRLRGS) + 1;
+}
+
+static int vgic_v3_highest_priority_lr(struct cpu_user_regs *regs,
+   uint32_t vmcr, uint64_t *lr_val)
+{
+unsigned int i, lr = -1;
+unsigned int used_lrs =  gic_get_num_lrs();
+uint8_t priority = GICV3_IDLE_PRIORITY;
+
+for ( i = 0; i < used_lrs; i++ )
+{
+uint64_t val =  gicv3_ich_read_lr(i);
+uint8_t lr_prio = (val & ICH_LR_PRIORITY_MASK) >> 
ICH_LR_PRIORITY_SHIFT;
+
+/* Not pending in the state? */
+if ( (val & ICH_LR_STATE) != ICH_LR_PENDING_BIT )
+continue;
+
+/* Group-0 interrupt, but Group-0 disabled? */
+if ( !(val & ICH_LR_GROUP) && !(vmcr & ICH_VMCR_ENG0_MASK) )
+continue;
+
+/* Group-1 interrupt, but Group-1 disabled? */
+if ( (val & ICH_LR_GROUP) && !(vmcr & ICH_VMCR_ENG1_MASK) )
+continue;
+
+/* Not the highest priority? */
+if ( lr_prio >= priority )
+continue;
+
+/* This is a candidate */
+priority = lr_prio;
+*lr_val = val;
+lr = i;
+}
+
+if ( lr == -1 )
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+return lr;
+}
+
+static int vgic_v3_get_highest_active_priority(void)
+{
+unsigned int i;
+uint32_t hap = 0;
+uint8_t nr_apr_regs = vtr_to_nr_apr_regs(READ_SYSREG32(ICH_VTR_EL2));
+
+for ( i = 0; i < nr_apr_regs; i++ )
+{
+uint32_t val;
+
+/*
+ * The ICH_AP0Rn_EL2 and ICH_AP1Rn_EL2 registers
+ * contain the active priority levels for this VCPU
+ * for the maximum number of supported priority
+ * levels, and we return the full priority level only
+ * if the BPR is programmed to its minimum, otherwise
+ * we return a combination of the priority level and
+ * subpriority, as determined by the setting of the
+ * BPR, but without the full subpriority.
+ */
+val  = vgic_v3_read_ap0rn(i);
+val |= vgic_v3_read_ap1rn(i);
+if ( !val )
+{
+hap += 32;
+continue;
+}
+
+return (hap + __ffs(val)) << vgic_v3_bpr_min();
+}
+
+return GICV3_IDLE_PRIORITY;
+}
+
+/*
+ * Convert a priority to a preemption level, taking the relevant BPR
+ * into account by zeroing the sub-priority bits.
+ */
+static uint8_t vgic_v3_pri_to_pre(uint8_t pri, uint32_t vmcr, int grp)
+{
+unsigned int bpr;
+
+if ( !grp )
+bpr = vgic_v3_get_bpr0(vmcr) + 1;
+else
+bpr = vgic_v3_get_bpr1(vmcr);
+
+return pri & (GENMASK(7, 0) << bpr);
+}
+
+/*
+ * The priority value is independent of any of the BPR values, so we
+ * normalize it using the minumal BPR value. This guarantees that no
+ * matter what the guest does with its BPR, we can always set/get the
+ * same value of a priority.
+ */
+static void vgic_v3_set_active_priority(uint8_t pri, uint32_t vmcr, int grp)
+{
+uint8_t pre, ap;
+uint32_t val;
+int apr;
+
+pre = vgic_v3_pri_to_pre(pri, vmcr, grp);
+ap = pre >> vgic_v3_bpr_min();
+apr = ap / 32;
+
+if ( !grp )
+{
+val = vgic_v3_read_ap0rn

[Xen-devel] [PATCH v2 05/17] Expose ich_read/write_lr in vgic-v3-sr.c

[Manish Jaggi]

gicv3_ich_read/write_lr functions are duplicated in vgic-v3-sr.c
This is done to make the file independent of the xen vgic code for
handling the errata.

Both the functions in the patch are static, so this patch needs
subsequent patches to compile without error (unused function)

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
 xen/arch/arm/arm64/vgic-v3-sr.c | 83 +
 1 file changed, 83 insertions(+)

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 48346ed628..fc5246539e 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -209,6 +209,89 @@ static uint32_t vgic_v3_read_ap1rn(int n)
 return val;
 }
 
+static uint64_t gicv3_ich_read_lr(int lr)
+{
+switch ( lr )
+{
+case 0: return READ_SYSREG(ICH_LR0_EL2);
+case 1: return READ_SYSREG(ICH_LR1_EL2);
+case 2: return READ_SYSREG(ICH_LR2_EL2);
+case 3: return READ_SYSREG(ICH_LR3_EL2);
+case 4: return READ_SYSREG(ICH_LR4_EL2);
+case 5: return READ_SYSREG(ICH_LR5_EL2);
+case 6: return READ_SYSREG(ICH_LR6_EL2);
+case 7: return READ_SYSREG(ICH_LR7_EL2);
+case 8: return READ_SYSREG(ICH_LR8_EL2);
+case 9: return READ_SYSREG(ICH_LR9_EL2);
+case 10: return READ_SYSREG(ICH_LR10_EL2);
+case 11: return READ_SYSREG(ICH_LR11_EL2);
+case 12: return READ_SYSREG(ICH_LR12_EL2);
+case 13: return READ_SYSREG(ICH_LR13_EL2);
+case 14: return READ_SYSREG(ICH_LR14_EL2);
+case 15: return READ_SYSREG(ICH_LR15_EL2);
+default:
+unreachable();
+}
+}
+
+static void gicv3_ich_write_lr(int lr, uint64_t val)
+{
+switch ( lr )
+{
+case 0:
+WRITE_SYSREG(val, ICH_LR0_EL2);
+break;
+case 1:
+WRITE_SYSREG(val, ICH_LR1_EL2);
+break;
+case 2:
+WRITE_SYSREG(val, ICH_LR2_EL2);
+break;
+case 3:
+WRITE_SYSREG(val, ICH_LR3_EL2);
+break;
+case 4:
+WRITE_SYSREG(val, ICH_LR4_EL2);
+break;
+case 5:
+WRITE_SYSREG(val, ICH_LR5_EL2);
+break;
+case 6:
+WRITE_SYSREG(val, ICH_LR6_EL2);
+break;
+case 7:
+WRITE_SYSREG(val, ICH_LR7_EL2);
+break;
+case 8:
+WRITE_SYSREG(val, ICH_LR8_EL2);
+break;
+case 9:
+WRITE_SYSREG(val, ICH_LR9_EL2);
+break;
+case 10:
+WRITE_SYSREG(val, ICH_LR10_EL2);
+break;
+case 11:
+WRITE_SYSREG(val, ICH_LR11_EL2);
+break;
+case 12:
+WRITE_SYSREG(val, ICH_LR12_EL2);
+break;
+case 13:
+WRITE_SYSREG(val, ICH_LR13_EL2);
+break;
+case 14:
+WRITE_SYSREG(val, ICH_LR14_EL2);
+break;
+case 15:
+WRITE_SYSREG(val, ICH_LR15_EL2);
+break;
+default:
+return;
+}
+isb();
+}
+
 /*
  * returns true if the register is emulated.
  */
-- 
2.14.1


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

Re: [Xen-devel] [PATCH v1 06/15] arm64: Add accessors for the ICH_APxRn_EL2 registers

[Manish Jaggi]

Hi Marc,

I have a query on this patch. The original patch was using these 
functions so it was ok to make them static.
But this patch is not touching the xen vgic code similar to what your 
patch did.


Will it be ok to merge this patch with 
https://www.spinics.net/lists/arm-kernel/msg587089.html


-manish


On 03/16/2018 05:28 PM, Manish Jaggi wrote:

This patch is ported to xen from linux commit
63000dd8006dc987db31ba670edc23142ea91e01

As we're about to access the Active Priority registers a lot more,
let's define accessors that take the register number as a parameter.

This patch only has accessors, another patch will have register trap handlers

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 114d5107a9..1aaade40dc 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -114,6 +114,98 @@ void handle_igrpen1(struct cpu_user_regs *regs, int regidx,
  __vgic_v3_write_igrpen1(regs, regidx);
  }
  
+void  __vgic_v3_write_ap0rn(uint32_t val, int n)

+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP0R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP0R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP0R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+void __vgic_v3_write_ap1rn(uint32_t val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP1R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP1R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP1R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+uint32_t  __vgic_v3_read_ap0rn(int n)
+{
+uint32_t val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP0R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP0R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP0R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
+uint32_t  __vgic_v3_read_ap1rn(int n)
+{
+uint32_t val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP1R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP1R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP1R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
  bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
  {
  bool ret = true;



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

Re: [Xen-devel] [PATCH v1 04/15] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

On 03/21/2018 01:41 PM, Julien Grall wrote:

Hi Manish,

On 03/16/2018 11:58 AM, Manish Jaggi wrote:

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>


As you port commit by commit, please at least mention Marc as he is 
the original author of that patch.
I have a little confusion, should a signoff be added once it is reviewed 
or even if it is ported?

I thought once it is acked, we add signoff.

Please suggest.



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

Re: [Xen-devel] [PATCH v1 05/15] arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

[Manish Jaggi]

Hi Julien,


On 03/21/2018 02:08 PM, Julien Grall wrote:



On 03/16/2018 11:58 AM, Manish Jaggi wrote:

This patch is ported to xen from linux commit:
f8b630bc542e0368886ae193d3519c832b270359

Add a handler for reading/writing the guest's view of the
ICC_IGRPEN1_EL1


The wrapping looks wrong.


register, which is located in the ICH_VMCR_EL2.VENG1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c 
b/xen/arch/arm/arm64/vgic-v3-sr.c

index 364785d3ac..114d5107a9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -86,6 +86,34 @@ void handle_bpr1(struct cpu_user_regs *regs, int 
regidx, const union hsr hsr)

  __vgic_v3_write_bpr1(regs, regidx);
  }
  +static void  __vgic_v3_read_igrpen1(struct cpu_user_regs *regs, 
int regidx)


Please remove the __ for all the functions.

ok



+{
+    uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);


Newline.

For 2 line function should there be a newline?
Will add it.



+    set_user_reg(regs, regidx, !!(vmcr & ICH_VMCR_ENG1_MASK));
+}
+
+static void  __vgic_v3_write_igrpen1(struct cpu_user_regs *regs, int 
regidx)

+{
+    register_t val = get_user_reg(regs, regidx);
+    uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+    if ( val & 1 )
+    vmcr |= ICH_VMCR_ENG1_MASK;
+    else
+    vmcr &= ~ICH_VMCR_ENG1_MASK;
+
+    WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);


So basically, you ported commit without even looking if there were 
change on top. For instance the latest code has a specific has an 
helper to update vmcr. Can you please make sure that all the code is 
ported?



Well julien, I did that and it was in original code as well.
__vgic_v3_write_vmcr was called which was calling write_gicreg(vmcr, 
ICH_VMCR_EL2).

Xen aleady has a macro so it is better to use xen macro.

I can write that in commit log if that helps in easier review

+}
+
+void handle_igrpen1(struct cpu_user_regs *regs, int regidx,
+    const union hsr hsr)
+{
+    if ( hsr.sysreg.read )
+    __vgic_v3_read_igrpen1(regs, regidx);
+    else
+    __vgic_v3_write_igrpen1(regs, regidx);
+}
+
  bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const 
union hsr hsr)

  {
  bool ret = true;
@@ -105,6 +133,10 @@ bool vgic_v3_handle_cpuif_access(struct 
cpu_user_regs *regs, const union hsr hsr

   handle_bpr1(regs, regidx, hsr);
   break;
  +    case HSR_SYSREG_ICC_IGRPEN1_EL1:
+    handle_igrpen1(regs, regidx, hsr);
+    break;
+
  default:
  ret = false;
  break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h

index 025a27b0b4..731cabc74a 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -90,6 +90,7 @@
  #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
  #define HSR_SYSREG_ICC_SRE_EL1    HSR_SYSREG(3,0,c12,c12,5)
  #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
+#define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
  #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
    #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h

index 68a34cc353..ff8bda37d1 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -163,6 +163,8 @@
  #define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
  #define ICH_VMCR_BPR1_SHIFT  18
  #define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
+#define ICH_VMCR_ENG1_SHIFT  1
+#define ICH_VMCR_ENG1_MASK   (1 << ICH_VMCR_ENG1_SHIFT)
    #define GICH_LR_VIRTUAL_MASK 0x
  #define GICH_LR_VIRTUAL_SHIFT    0



Cheers,



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

Re: [Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

[Manish Jaggi]

On 03/23/2018 12:28 PM, Julien Grall wrote:

(Sorry for the formatting)

On 23 Mar 2018 14:46, "Manish Jaggi" <mja...@caviumnetworks.com 
<mailto:mja...@caviumnetworks.com>> wrote:




On 03/21/2018 03:26 PM, Julien Grall wrote:

Hi Manish,

On 03/21/2018 09:38 AM, Manish Jaggi wrote:



On 03/21/2018 02:15 PM, Julien Grall wrote:



On 03/21/2018 04:58 AM, Manish Jaggi wrote:


Hi Julien,

On 03/20/2018 01:16 PM, Julien Grall wrote:



On 03/16/2018 11:58 AM, Manish Jaggi wrote:

This patchset is a Xen port of Marc's
patchset.
arm64: KVM: Mediate access to GICv3
sysregs at EL2 [1]

The current RFC patchset is a subset of
[1], as it handleing only Group1 traps
as a PoC. Most of the trap code is added
in vsysreg.c. Trap handler function is kept
independent of the usual guest trap
handling code.
Looking for feedback on this approach.


This cover letter does not seem to match the
series. Please update it on every time you
send a series.

%s/vsysreg.c/vgic-v3-sr..

Could you please review the other patches in the
series, so that I can send v2.


Here the major comments for the series (included patch
not reviewed):
1) You seem to miss some patches from Linux. I
would like to understand why they are not there.

if code is ported to xen, it is perfectly fine to take
only relevant patches.


It is usually expected from the contributor to have some sort
of explanation in the cover letter. In particular when you are
based on a series from Linux.

Where I am more worried is there are patch on top in Linux,
that you didn't backport. So it would be really nice to
understand why those patches are not in Xen.

A non-exhaustive list:
- KVM: arm64: Log an error if trapping a
write-to-read-only GICv3 access
    - KVM: arm64: Log an error if trapping a
read-from-write-only GICv3 access


For instance we are not providing any command line option
to individually enable group1 grou0 traps.


I think the command line option could be useful for testing.
Developer don't necessarily have a Thunder-X in hand.

2) Strangely some commits does not match the Linux
one either in order and content (I am not speaking
about the changes required by Xen). For instance this
is the case of patch #14 "arm64: vgic-v3: Add
ICV_AP(0/1)Rn_EL1 handler". If you port commit from
Linux, then you should follow the same. This help a
lot for review.

Since we are not doing individually enable of group0/1, it
doesnt make sense to have two set of patches for ICV_AP0 /
ICV_AP1. So I merged it.


Sorry, but it does not make sense. Looking at the series you
pointed. I don't see a patch just for ICV_AP0. Instead it is
part of " KVM: arm64: vgic-v3: Enable trapping of Group-0
system registers". You ported that patch in Xen.

If you see this patch, you will find this one specifically for ICV_AP1
https://lists.cs.columbia.edu/pipermail/kvmarm/2017-June/026040.html
<https://lists.cs.columbia.edu/pipermail/kvmarm/2017-June/026040.html>


You didn't get my point...  You still don't explain why you move the 
ICV_AP0 from "Enable trapping of Group-0 system registers"  to that 
patch. If you take commit from Linux then don't move code between 
commit around unless there is a good reason.
I gave a good reason, that it make sense to club two patches as we are 
not individually enabling g0/g1 for 30115 errata.
There is no documented rule that code taken from linux has to be 1:1 
mapping with linux patch.

When complete smmu.c is taken as one file the rule is not applied?



Please try to make the review a bit easier...

Cheers,



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

Re: [Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

[Manish Jaggi]

On 03/21/2018 03:26 PM, Julien Grall wrote:

Hi Manish,

On 03/21/2018 09:38 AM, Manish Jaggi wrote:



On 03/21/2018 02:15 PM, Julien Grall wrote:



On 03/21/2018 04:58 AM, Manish Jaggi wrote:


Hi Julien,

On 03/20/2018 01:16 PM, Julien Grall wrote:



On 03/16/2018 11:58 AM, Manish Jaggi wrote:

This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]

The current RFC patchset is a subset of [1], as it handleing only 
Group1 traps
as a PoC. Most of the trap code is added in vsysreg.c. Trap 
handler function is kept

independent of the usual guest trap handling code.
Looking for feedback on this approach.


This cover letter does not seem to match the series. Please update 
it on every time you send a series.

%s/vsysreg.c/vgic-v3-sr..

Could you please review the other patches in the series, so that I 
can send v2.


Here the major comments for the series (included patch not reviewed):
1) You seem to miss some patches from Linux. I would like to 
understand why they are not there.
if code is ported to xen, it is perfectly fine to take only relevant 
patches.


It is usually expected from the contributor to have some sort of 
explanation in the cover letter. In particular when you are based on a 
series from Linux.


Where I am more worried is there are patch on top in Linux, that you 
didn't backport. So it would be really nice to understand why those 
patches are not in Xen.


A non-exhaustive list:
- KVM: arm64: Log an error if trapping a write-to-read-only GICv3 
access
    - KVM: arm64: Log an error if trapping a read-from-write-only 
GICv3 access



For instance we are not providing any command line option to 
individually enable group1 grou0 traps.


I think the command line option could be useful for testing. Developer 
don't necessarily have a Thunder-X in hand.


2) Strangely some commits does not match the Linux one either in 
order and content (I am not speaking about the changes required by 
Xen). For instance this is the case of patch #14 "arm64: vgic-v3: 
Add ICV_AP(0/1)Rn_EL1 handler". If you port commit from Linux, then 
you should follow the same. This help a lot for review.
Since we are not doing individually enable of group0/1, it doesnt 
make sense to have two set of patches for ICV_AP0 / ICV_AP1. So I 
merged it.


Sorry, but it does not make sense. Looking at the series you pointed. 
I don't see a patch just for ICV_AP0. Instead it is part of " KVM: 
arm64: vgic-v3: Enable trapping of Group-0 system registers". You 
ported that patch in Xen.



If you see this patch, you will find this one specifically for ICV_AP1
https://lists.cs.columbia.edu/pipermail/kvmarm/2017-June/026040.html

Cheers,




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

Re: [Xen-devel] [PATCH resend 03/13] acpi: arm: Code to generate Hardware Domains IORT

[Manish Jaggi]

On 03/23/2018 06:58 AM, Julien Grall wrote:

Hi Manish,

On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:

From: Manish Jaggi <mja...@caviumnetworks.com>

Structure of Hardware domain's (hwdom) IORT

hwdom's IORT will only have PCIRC nodes and ITS group nodes
in the following order. SMMU nodes as they are hidden from hardware
domain.

[IORT Header]
[ITS Group 1 ]
...
[ITS Group n ]
[PCIRC Node 1]
   [PCIRC IDMAP entry 1]
   ...
   [PCIRC IDMAP entry m]
...
[PCIRC Node p]
   [PCIRC IDMAP entry 1]
   ...
   [PCIRC IDMAP entry q]
...
*n,m,p are variable.

requesterid-deviceid mapping list (rid_devid_list) populated by
parsing IORT is used to generate hwdom IORT.

As the rid_devid_list is populated from firmware IORT, IDMAP entry
would have output references offsets based on firmware's IORT.
It is required to fixup node offset of ITS Group Nodes in the PCIRC
idmap (output_reference)

First write all the ITS group nodes in the hwdom's IORT. For this
write_hwits_nodes is called, which parses the rid_devid_list and for
each unique its_node in firmware IORT create a its_node in hwdom's
IORT and also creates and entry in fwits_hwits_map.

fwits_hwits_map is a mapping between firmware IORT's its node
and the node offset of the corresponding its_node stored in the
hwdom's IORT.

This map can later be used to set output reference value in hwdom's
pcirc node's idmap entries.

Signed-off-by: Manish Jaggi <manish.ja...@linaro.org>
---
  xen/arch/arm/acpi/gen-iort.c    | 299 


  xen/arch/arm/domain_build.c |  35 +
  xen/include/asm-arm/acpi.h  |   1 +
  xen/include/asm-arm/acpi/gen-iort.h |  11 ++
  4 files changed, 346 insertions(+)

diff --git a/xen/arch/arm/acpi/gen-iort.c b/xen/arch/arm/acpi/gen-iort.c
index 687c4f18ee..251a9771e3 100644
--- a/xen/arch/arm/acpi/gen-iort.c
+++ b/xen/arch/arm/acpi/gen-iort.c
@@ -19,6 +19,305 @@
    #include 
  #include 
+#include 
+
+/*
+ * Structure of Hardware domain's (hwdom) IORT
+ * ---
+ *
+ * hwdom's IORT will only have PCIRC nodes and ITS group nodes
+ * in the following order.
+ *
+ * [IORT Header]
+ * [ITS Group 1 ]
+ * ...
+ * [ITS Group N ]
+ * [PCIRC Node 1]
+ * [PCIRC IDMAP entry 1]
+ * ...
+ * [PCIRC IDMAP entry N]
+ * ...
+ * [PCIRC Node N]
+ *
+ * requesterid-deviceid mapping list (rid_devid_list) populated by 
parsing IORT

+ * is used to generate hwdom IORT.
+ *
+ * One of the challanges is to fixup node offset of ITS Group Nodes


s/challanges/challenges/


+ * in the PCIRC idmap (output_reference)
+ *
+ * In rid_devid_map firmware IORT's ITS group node pointer in stored.
+ *
+ * We first write all the ITS group nodes in the hwdom's IORT. For this
+ * write_hwits_nodes is called, which parses the rid_devid_list and for
+ * each unique its_node in firmware IORT create a its_node in 
hwdom's IORT

+ * and also creates and entry in fwits_hwits_map.
+ *
+ * fwits_hwits_map is a mapping between firmware IORT's its node
+ * and the node offset of the corresponding its_node stored in the
+ * hwdom's IORT.
+ *
+ * This map can be later used to set output reference value in hwdom's
+ * pcirc node's idmap entries.
+ *
+ */
+
+/*
+ * Stores the mapping between firmware tables its group node
+ * to the offset of the equivalent its node to be stored in
+ * hwdom's IORT.
+ */
+struct fwits_hwits_map
+{
+    struct acpi_iort_node *fwits_node;
+    unsigned int hwitsnode_offset;
+    struct list_head entry;
+};
+
+LIST_HEAD(fwits_hwits_list);


As said in the previous version, I think this should be static.


+
+/*
+ * is_uniq_fwits_node
+ *
+ * returns 1 - if fwits_node is not already in the its_map_list
+ * 0 - if it is present already


It also returns -ENOMEM when you can't allocate memory.


+ *
+ * fwits_node - ITS Node pointer in Firmware IORT
+ * offset - offset of the equivalent its node to be stored in
+ *  hwdom's IORT
+ */
+static int is_uniq_fwits_node(struct acpi_iort_node *fwits_node,


The name is a bit odd given that you add the ITS node. On the previous 
version, I requested to document that behavior...
I think the name is quite appropriate. Also in this patch I have added 
description of the flow so this should be fairly intuitive.
Could you please let me know the specific point you dont understand, I 
can explain that.


But you likely want to rename the function to add_fwits_node(...) or 
something similar.

I think name is quite appropriate.



+  unsigned int offset)
+{
+    struct fwits_hwits_map *map;
+
+    list_for_each_entry(map, _hwits_list, entry)
+    {
+    if ( map->fwits_node == fwits_node )
+    return 0;
+    }
+
+    map = xzalloc(struct fwits_hwits_map);


Where this memory is going to be freed?

Since this list can be used multiple times even after creation of IORT 
for dom0, say thinking ahead for domUs.

+    if ( !map )
+    return -ENOMEM;
+
+    

Re: [Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

[Manish Jaggi]

On 03/21/2018 02:15 PM, Julien Grall wrote:



On 03/21/2018 04:58 AM, Manish Jaggi wrote:


Hi Julien,

On 03/20/2018 01:16 PM, Julien Grall wrote:



On 03/16/2018 11:58 AM, Manish Jaggi wrote:

This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]

The current RFC patchset is a subset of [1], as it handleing only 
Group1 traps
as a PoC. Most of the trap code is added in vsysreg.c. Trap handler 
function is kept

independent of the usual guest trap handling code.
Looking for feedback on this approach.


This cover letter does not seem to match the series. Please update 
it on every time you send a series.

%s/vsysreg.c/vgic-v3-sr..

Could you please review the other patches in the series, so that I 
can send v2.


Here the major comments for the series (included patch not reviewed):
1) You seem to miss some patches from Linux. I would like to 
understand why they are not there.
if code is ported to xen, it is perfectly fine to take only relevant 
patches.
For instance we are not providing any command line option to 
individually enable group1 grou0 traps.
2) Strangely some commits does not match the Linux one either in 
order and content (I am not speaking about the changes required by 
Xen). For instance this is the case of patch #14 "arm64: vgic-v3: Add 
ICV_AP(0/1)Rn_EL1 handler". If you port commit from Linux, then you 
should follow the same. This help a lot for review.
Since we are not doing individually enable of group0/1, it doesnt make 
sense to have two set of patches for ICV_AP0 / ICV_AP1. So I merged it.

3)

Code organization:
1) Please drop __ from all functions

ok I will change.
2) All functions not exported *should* be static. At the same time 
you need to make sure that the series are bisectable. So you probably 
hook the file in the build system at the end rather than in #3.



ok.

Cheers,





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

Re: [Xen-devel] [PATCH resend 01/13] acpi: arm: API: Populate/query rid-devid rid-sid map.

[Manish Jaggi]

On 03/21/2018 02:59 PM, Julien Grall wrote:

Hi Manish,

Hi Julien,


On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:

From: Manish Jaggi <mja...@caviumnetworks.com>

IORT has a hierarchical structure containing PCIRC nodes, IORT nodes
and SMMU nodes. Each node has with it an array of ids and a mapping
which maps a range of ids to another node's ids.
PCIRC(requesterid)->SMMU(streamid)->ITS(devid) or PCIRC->ITS

IORT is parsed multiple times when streamid(sid) / deviceid(devid)
is queried from requesterid (rid).

Xen needs to prepare IORT for hardware domain which might again
require parsing. Thus it is prudent to parse IORT once and save
mapping information into individual maps namely rid-sid rid-devid.

This patch provides API to add a new mapping and query sid/devid based
on rid. Two lists are created rid-sid list, rid-devid list.
rid-devid list forms the basis of hardware domains' IORT.


Thank you for updating the commit message. However, you stil don't 
give an idea often those function will get called and whether unsorted 
list will be fine.

I have added that in code comments.




Signed-off-by: Manish Jaggi <manish.ja...@linaro.org>
---
  xen/arch/arm/acpi/Makefile    |   1 +
  xen/arch/arm/acpi/ridmap.c    | 126 
++
  xen/include/asm-arm/acpi/ridmap.h | 112 
+

  3 files changed, 239 insertions(+)

diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
index 23963f8fa0..eb7e8ce4f7 100644
--- a/xen/arch/arm/acpi/Makefile
+++ b/xen/arch/arm/acpi/Makefile
@@ -1,2 +1,3 @@
  obj-y += lib.o
  obj-y += boot.init.o
+obj-y += ridmap.o
diff --git a/xen/arch/arm/acpi/ridmap.c b/xen/arch/arm/acpi/ridmap.c
new file mode 100644
index 00..daa137f625
--- /dev/null
+++ b/xen/arch/arm/acpi/ridmap.c
@@ -0,0 +1,126 @@
+/*
+ * xen/drivers/acpi/arm/ridmap.c
+ *
+ * This file implements rid-sid rid-devid mapping API
+ *
+ * Manish Jaggi <manish.ja...@linaro.org>
+ * Copyright (c) 2018 Linaro.
+ *
+ * Ths program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+LIST_HEAD(rid_sid_list);
+LIST_HEAD(rid_devid_list);
+
+int add_rid_sid_map(struct acpi_iort_node *pcirc_node,
+    struct acpi_iort_node *smmu_node,


Is there any one that will modify pcirc_node and smmu_node afterwards? 
If not, then they should be const.



+    uint32_t input_base, uint32_t output_base,
+    uint32_t id_count)


I suggested to put __init in front of that function. But you dismissed 
it saying it might not be valid and you will add rationale. I don't 
see any rationale in that patch nor an answer to my question on the 
previous version.



Should a public API function be __init ?

+{
+    struct rid_sid_map *rid_map;
+
+    rid_map = xzalloc(struct rid_sid_map);
+    if ( !rid_map )
+    return -ENOMEM;
+
+    rid_map->idmap.input_base = input_base;
+    rid_map->idmap.output_base = output_base;
+    rid_map->idmap.id_count = id_count;
+    rid_map->pcirc_node = pcirc_node;
+    rid_map->smmu_node = smmu_node;
+
+    list_add_tail(_map->entry, _sid_list);
+
+    return 0;
+}
+
+int add_rid_devid_map(struct acpi_iort_node *pcirc_node,
+  struct acpi_iort_node *its_node,


Same here about const.


+  uint32_t input_base, uint32_t output_base,
+  uint32_t id_count)


Same here about __init.


+{
+    struct rid_devid_map *rid_map;
+
+    rid_map = xzalloc(struct rid_devid_map);
+    if ( !rid_map )
+    return -ENOMEM;
+
+    rid_map->idmap.input_base = input_base;
+    rid_map->idmap.output_base = output_base;
+    rid_map->idmap.id_count = id_count;
+    rid_map->pcirc_node = pcirc_node;
+    rid_map->its_node = its_node;
+
+    list_add_tail(_map->entry, _devid_list);
+
+    return 0;
+}
+
+bool query_sid(struct acpi_iort_node *pcirc_node, uint32_t rid,
+   uint32_t *sid, struct acpi_iort_node **smmu_node)
+{
+    struct rid_sid_map *rmap;
+
+    list_for_each_entry(rmap, _sid_list, entry)
+    {
+    if ( rmap->pcirc_node == pcirc_node )
+    {
+    if ( (rid >= rmap->idmap.input_base) &&
+ (rid < rmap->idmap.input_base + 
rmap->idmap.id_count) )

+    {
+    *sid = rid - rmap->idmap.input_base +
+   rmap->idmap.output_base;
+    *smmu_node = rmap->smmu_node;
+
+   

Re: [Xen-devel] [PATCH v1 02/15] arm64: Add config for Cavium Thunder erratum 30115

[Manish Jaggi]

On 03/20/2018 01:13 PM, Julien Grall wrote:

Hi,

On 03/16/2018 11:58 AM, Manish Jaggi wrote:

Some Cavium Thunder CPUs suffer a problem where a Xen guest may
inadvertently cause the host kernel to quit receiving interrupts.
This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will
provide workaround.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/docs/misc/arm/silicon-errata.txt 
b/docs/misc/arm/silicon-errata.txt

index c9854c39f4..a2546d4bb5 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -48,3 +48,4 @@ stable hypervisors.
  | ARM    | Cortex-A57  | #852523 | 
N/A |
  | ARM    | Cortex-A57  | #832075 | 
ARM64_ERRATUM_832075    |
  | ARM    | Cortex-A57  | #834220 | 
ARM64_ERRATUM_834220    |
+| CAVIUM | ThunderX1   | #30115  | 
CAVIUM_ERRATUM_30115    |

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index f58019d6ed..762b761f7d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -169,6 +169,17 @@ config ARM64_ERRATUM_834220
      If unsure, say Y.
  +config CAVIUM_ERRATUM_30115
+    bool "Cavium Erratum 30115"
+    depends on HAS_GICV3
+    help
+  On ThunderX T88 pass 1.x through 2.2, T81 pass 1.0 through
+  1.2, and T83 Pass 1.0, guest execution may disable
+  interrupts in host. Trapping both GICv3 group-0 and group-1
+  accesses sidesteps the issue.
+
+  If unsure, say Y.
+
  endmenu
    source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index fe9e9facbe..d49698f785 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -56,6 +56,27 @@ static const struct arm_cpu_capabilities 
arm_errata[] = {

  MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
 (1 << MIDR_VARIANT_SHIFT) | 2),
  },
+#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+    {
+    /* Cavium ThunderX, T88 pass 1.x - 2.2 */


This is quite odd. You specify a number in the commit message here, 
but in the previous one you just say "thunderx1". Can you please try 
to agree on the name? Like the right naming is MIDR_THUNDERX_88.

ThunderX1 is 88xx. Also this patch is using the same patch from linux.
Please see 
https://lists.cs.columbia.edu/pipermail/kvmarm/2017-June/025815.html





+    .desc = "Cavium erratum 30115",
+    .capability = ARM64_WORKAROUND_CAVIUM_30115,
+    MIDR_RANGE(MIDR_THUNDERX, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+    },
+    {
+    /* Cavium ThunderX, T81 pass 1.0 - 1.2 */
+    .desc = "Cavium erratum 30115",
+    .capability = ARM64_WORKAROUND_CAVIUM_30115,
+    MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x02),
+    },
+    {
+    /* Cavium ThunderX, T83 pass 1.0 */
+    .desc = "Cavium erratum 30115",
+    .capability = ARM64_WORKAROUND_CAVIUM_30115,
+    MIDR_RANGE(MIDR_THUNDERX_83XX, 0x00, 0x00),
+    },
  #endif
  {},
  };
diff --git a/xen/include/asm-arm/cpuerrata.h 
b/xen/include/asm-arm/cpuerrata.h

index 8b158429c7..521f03521b 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -41,6 +41,7 @@ static inline bool 
check_workaround_##erratum(void) \
    CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, 
CONFIG_ARM_32)
  CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, 
CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(30115, ARM64_WORKAROUND_CAVIUM_30115, 
CONFIG_ARM_64)


Please add cavium_ in the erratum name. So it is easy to know where 
the erratum is from.

ok



    #undef CHECK_WORKAROUND_HELPER
  diff --git a/xen/include/asm-arm/cpufeature.h 
b/xen/include/asm-arm/cpufeature.h

index f00b6dbd39..d409636bf0 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -42,8 +42,9 @@
  #define LIVEPATCH_FEATURE   4
  #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
  #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
+#define ARM64_WORKAROUND_CAVIUM_30115 7
  -#define ARM_NCAPS   7
+#define ARM_NCAPS   8
    #ifndef __ASSEMBLY__



Cheers,




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

Re: [Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

[Manish Jaggi]

Hi Julien,

On 03/20/2018 01:16 PM, Julien Grall wrote:



On 03/16/2018 11:58 AM, Manish Jaggi wrote:

This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]

The current RFC patchset is a subset of [1], as it handleing only 
Group1 traps
as a PoC. Most of the trap code is added in vsysreg.c. Trap handler 
function is kept

independent of the usual guest trap handling code.
Looking for feedback on this approach.


This cover letter does not seem to match the series. Please update it 
on every time you send a series.

%s/vsysreg.c/vgic-v3-sr..

Could you please review the other patches in the series, so that I can 
send v2.


Cheers,




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

[Xen-devel] [PATCH v1 15/15] Enable Group0/1 Traps by default for Cavium ThunderX1

[Manish Jaggi]

Enable trapping for Group0/1 register access when
CONFIG_CAVIUM_ERRATUM_30115 is enabled.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 473e26111f..6ffed6a634 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -825,7 +826,7 @@ static void gicv3_cpu_disable(void)
 
 static void gicv3_hyp_init(void)
 {
-uint32_t vtr;
+uint32_t vtr, hcr = GICH_HCR_EN;
 
 vtr = READ_SYSREG32(ICH_VTR_EL2);
 gicv3_info.nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
@@ -836,7 +837,14 @@ static void gicv3_hyp_init(void)
 panic("GICv3: Invalid number of priority bits\n");
 
 WRITE_SYSREG32(GICH_VMCR_EOI | GICH_VMCR_VENG1, ICH_VMCR_EL2);
-WRITE_SYSREG32(GICH_HCR_EN, ICH_HCR_EL2);
+
+if ( cpus_have_cap(ARM64_WORKAROUND_CAVIUM_30115) )
+{
+hcr |= GICH_HCR_TALL1;
+hcr |= GICH_HCR_TALL0;
+}
+
+ WRITE_SYSREG32(hcr, ICH_HCR_EL2);
 }
 
 /* Set up the per-CPU parts of the GIC for a secondary CPU */
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index d3d7bda50d..c76a330b6b 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -117,6 +117,8 @@
 #define GICH_HCR_VGRP0DIE (1 << 5)
 #define GICH_HCR_VGRP1EIE (1 << 6)
 #define GICH_HCR_VGRP1DIE (1 << 7)
+#define GICH_HCR_TALL1(1 << 12)
+#define GICH_HCR_TALL0(1 << 11)
 
 #define GICH_MISR_EOI (1 << 0)
 #define GICH_MISR_U   (1 << 1)
-- 
2.14.1


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

[Xen-devel] [PATCH v1 14/15] arm64: vgic-v3: Add ICV_AP(0/1)Rn_EL1 handler

[Manish Jaggi]

This patch is a xen port of linux commit 
f9e7449c780f688bf61a13dfa8c344afeb4ad6e0.

Add a handler for reading/writing the guest's view of the ICV_AP1Rn_EL1
registers. We just map them to the corresponding ICH_AP(0/1)Rn_EL2 registers.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 5af5142b21..2ca1145336 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -694,6 +694,66 @@ spurious:
 set_user_reg(regs, regidx, lr_val & ICH_LR_VIRTUAL_ID_MASK);
 }
 
+static void  __vgic_v3_read_apxrn(struct cpu_user_regs *regs, int regidx,
+  const union hsr hsr, int n)
+{
+uint32_t val;
+
+if ( !__vgic_v3_get_group(hsr) )
+val = __vgic_v3_read_ap0rn(n);
+else
+val = __vgic_v3_read_ap1rn(n);
+
+   set_user_reg(regs, regidx, val);
+}
+
+static void  __vgic_v3_write_apxrn(struct cpu_user_regs *regs, int regidx,
+   const union hsr hsr, int n)
+{
+uint32_t val = get_user_reg(regs, regidx);
+
+if (!__vgic_v3_get_group(hsr))
+__vgic_v3_write_ap0rn(val, n);
+else
+__vgic_v3_write_ap1rn(val, n);
+}
+
+void handle_apxr0(struct cpu_user_regs *regs, int regidx,
+ const union hsr hsr)
+{
+if(hsr.sysreg.read)
+__vgic_v3_read_apxrn(regs, regidx, hsr, 0);
+else
+__vgic_v3_write_apxrn(regs, regidx, hsr, 0);
+}
+
+void handle_apxr1(struct cpu_user_regs *regs, int regidx,
+ const union hsr hsr)
+{
+if(hsr.sysreg.read)
+__vgic_v3_read_apxrn(regs, regidx, hsr, 1);
+else
+__vgic_v3_write_apxrn(regs, regidx, hsr, 1);
+}
+
+void handle_apxr2(struct cpu_user_regs *regs, int regidx,
+ const union hsr hsr)
+{
+if(hsr.sysreg.read)
+__vgic_v3_read_apxrn(regs, regidx, hsr, 2);
+else
+__vgic_v3_write_apxrn(regs, regidx, hsr, 2);
+}
+
+void handle_apxr3(struct cpu_user_regs *regs, int regidx,
+ const union hsr hsr)
+{
+if(hsr.sysreg.read)
+__vgic_v3_read_apxrn(regs, regidx, hsr, 3);
+else
+__vgic_v3_write_apxrn(regs, regidx, hsr, 3);
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = true;
@@ -740,6 +800,26 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
 handle_hppir1(regs, regidx, hsr);
 break;
 
+case HSR_SYSREG_ICC_AP0Rn_EL1(0):
+case HSR_SYSREG_ICC_AP1Rn_EL1(0):
+handle_apxr0(regs, regidx, hsr);
+break;
+
+case HSR_SYSREG_ICC_AP0Rn_EL1(1):
+case HSR_SYSREG_ICC_AP1Rn_EL1(1):
+handle_apxr1(regs, regidx, hsr);
+break;
+
+case HSR_SYSREG_ICC_AP0Rn_EL1(2):
+case HSR_SYSREG_ICC_AP1Rn_EL1(2):
+handle_apxr2(regs, regidx, hsr);
+break;
+
+case HSR_SYSREG_ICC_AP0Rn_EL1(3):
+case HSR_SYSREG_ICC_AP1Rn_EL1(3):
+handle_apxr3(regs, regidx, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 8d1bd12348..e446b5de1c 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -85,6 +85,17 @@
 #define HSR_SYSREG_PMINTENCLR_EL1 HSR_SYSREG(3,0,c9,c14,2)
 #define HSR_SYSREG_MAIR_EL1   HSR_SYSREG(3,0,c10,c2,0)
 #define HSR_SYSREG_AMAIR_EL1  HSR_SYSREG(3,0,c10,c3,0)
+#define HSR_SYSREG_ICC_AP0Rn_EL1(n) HSR_SYSREG(3,0,c12,c8,4|n)
+#define HSR_SYSREG_ICC_AP0R0_EL1   HSR_SYSREG_ICC_AP0Rn_EL1(0)
+#define HSR_SYSREG_ICC_AP0R1_EL1   HSR_SYSREG_ICC_AP0Rn_EL1(1)
+#define HSR_SYSREG_ICC_AP0R2_EL1   HSR_SYSREG_ICC_AP0Rn_EL1(2)
+#define HSR_SYSREG_ICC_AP0R3_EL1   HSR_SYSREG_ICC_AP0Rn_EL1(3)
+#define HSR_SYSREG_ICC_AP1Rn_EL1(n)HSR_SYSREG(3,0,c12,c9, n)
+#define HSR_SYSREG_ICC_AP1R0_EL1   HSR_SYSREG_ICC_AP1Rn_EL1(0)
+#define HSR_SYSREG_ICC_AP1R1_EL1   HSR_SYSREG_ICC_AP1Rn_EL1(1)
+#define HSR_SYSREG_ICC_AP1R2_EL1   HSR_SYSREG_ICC_AP1Rn_EL1(2)
+#define HSR_SYSREG_ICC_AP1R3_EL1   HSR_SYSREG_ICC_AP1Rn_EL1(3)
+
 #define HSR_SYSREG_ICC_SGI1R_EL1  HSR_SYSREG(3,0,c12,c11,5)
 #define HSR_SYSREG_ICC_ASGI1R_EL1 HSR_SYSREG(3,1,c12,c11,6)
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
-- 
2.14.1


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

[Xen-devel] [PATCH v1 13/15] arm64: vgic-v3: Add misc Group-0 handlers

[Manish Jaggi]

This patch is ported to xen from linux commit:
eab0b2dc4f6f34147e3d10da49ab8032e15dbea0

A number of Group-0 registers can be handled by the same accessors
as that of Group-1, so let's add the required system register encodings
and catch them in the dispatching function.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 8951a75481..5af5142b21 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -725,14 +725,17 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
 handle_igrpen1(regs, regidx, hsr);
 break;
 
+case HSR_SYSREG_ICC_IAR0_EL1:
 case HSR_SYSREG_ICC_IAR1_EL1:
 handle_iar(regs, regidx, hsr);
 break;
 
+case HSR_SYSREG_ICC_EOIR0_EL1:
 case HSR_SYSREG_ICC_EOIR1_EL1:
 handle_eoi(regs, regidx, hsr);
 break;
 
+case HSR_SYSREG_ICC_HPPIR0_EL1:
 case HSR_SYSREG_ICC_HPPIR1_EL1:
 handle_hppir1(regs, regidx, hsr);
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index f9049a6b04..8d1bd12348 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -95,6 +95,9 @@
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
+#define HSR_SYSREG_ICC_IAR0_EL1   HSR_SYSREG(3,0,c12,c8,0)
+#define HSR_SYSREG_ICC_EOIR0_EL1  HSR_SYSREG(3,0,c12,c8,1)
+#define HSR_SYSREG_ICC_HPPIR0_EL1 HSR_SYSREG(3,0,c12,c8,2)
 #define HSR_SYSREG_ICC_BPR0_EL1  HSR_SYSREG(3,0,c12,c8,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
-- 
2.14.1


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

[Xen-devel] [PATCH v1 00/15] arm64: Mediate access to GICv3 sysregs at EL2

[Manish Jaggi]

This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]

The current RFC patchset is a subset of [1], as it handleing only Group1 traps
as a PoC. Most of the trap code is added in vsysreg.c. Trap handler function is 
kept
independent of the usual guest trap handling code.
Looking for feedback on this approach.

The errata has been validated on Cavium ThunderX platform.

Steps to reporduce the errata
- Boot Xen with 2 cores.
- Disable group1 interrupts in domU kernel
- start domU, the kill and start again.
One of the Xen core would hang.

Code in this patchset fixes this issue.

[1] https://lists.cs.columbia.edu/pipermail/kvmarm/2017-June/026029.html

Changes from v0
- Added Group0 traps.
- Some cleanups and documentation

Changes from RFC
- Added commit information on ported patches from linux
- Added skip_hyp_tail to control calling leave_hypervisor_tail 
- Added CAVIUM_CONFIG_ERRATUM_30115 which will auto enable workaround

Manish Jaggi (15):
  arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family
  arm64: Add config for Cavium Thunder erratum 30115
  arm: Placeholder for handling Group0/1 traps for Cavium Erratum 30115
  arm64: vgic-v3: Add ICV_BPR1_EL1 handler
  arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler
  arm64: Add accessors for the ICH_APxRn_EL2 registers
  Expose ich_read/write_lr in vgic-v3-sr.c
  arm64: Add ICV_IAR1_EL1 handler
  arm64: vgic-v3: Add ICV_EOIR1_EL1 handler
  arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler
  arm64: vgic-v3: Add ICV_BPR0_EL1 handler
  arm64: vgic-v3: Add ICV_IGNREN0_EL1 handler
  arm64: vgic-v3: Add misc Group-0 handlers
  arm64: vgic-v3: Add ICV_AP(0/1)Rn_EL1 handler
  Enable Group0/1 Traps by default for Cavium ThunderX1

 docs/misc/arm/silicon-errata.txt|   1 +
 xen/arch/arm/Kconfig|  11 +
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/vgic-v3-sr.c | 841 
 xen/arch/arm/cpuerrata.c|  21 +
 xen/arch/arm/gic-v3.c   |  12 +-
 xen/arch/arm/traps.c|  31 ++
 xen/include/asm-arm/arm64/sysregs.h |  21 +
 xen/include/asm-arm/arm64/traps.h   |   3 +
 xen/include/asm-arm/cpuerrata.h |   1 +
 xen/include/asm-arm/cpufeature.h|   3 +-
 xen/include/asm-arm/current.h   |   3 +-
 xen/include/asm-arm/gic.h   |   2 +
 xen/include/asm-arm/gic_v3_defs.h   |  33 +-
 xen/include/asm-arm/processor.h |   9 +
 15 files changed, 987 insertions(+), 6 deletions(-)
 create mode 100644 xen/arch/arm/arm64/vgic-v3-sr.c

-- 
2.14.1


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

[Xen-devel] [PATCH v1 10/15] arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler

[Manish Jaggi]

This patch is ported from linux to xen
commit: 2724c11a1df4b22ee966c04809ea0e808f66b04e
(KVM: arm64: vgic-v3: Add ICV_HPPIR1_EL1 handler)

Add a handler for reading the guest's view of the ICV_HPPIR1_EL1
register. This is a simple parsing of the available LRs, extracting the
highest available interrupt.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 35bad3953f..537e164062 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -611,6 +611,26 @@ void handle_eoi(struct cpu_user_regs *regs, int regidx, 
const union hsr hsr)
 __vgic_v3_write_eoir(regs, regidx, hsr);
 }
 
+void handle_hppir1(struct cpu_user_regs *regs, int regidx, const union hsr hsr)
+{
+uint64_t lr_val;
+int lr, lr_grp, grp;
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+grp = __vgic_v3_get_group(hsr);
+lr = __vgic_v3_highest_priority_lr(regs, vmcr, _val);
+
+if ( lr == -1 )
+goto spurious;
+
+lr_grp = !!(lr_val & ICH_LR_GROUP);
+if ( lr_grp != grp )
+lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+spurious:
+set_user_reg(regs, regidx, lr_val & ICH_LR_VIRTUAL_ID_MASK);
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = true;
@@ -642,6 +662,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
 handle_eoi(regs, regidx, hsr);
 break;
 
+case HSR_SYSREG_ICC_HPPIR1_EL1:
+handle_hppir1(regs, regidx, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index f9110ebf9c..c23c4a33b2 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -93,6 +93,7 @@
 #define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
+#define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH v1 09/15] arm64: vgic-v3: Add ICV_EOIR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
b6f49035b4bf6e2709f2a5fed3107f5438c1fd02

Add a handler for writing the guest's view of the ICC_EOIR1_EL1
register. This involves dropping the priority of the interrupt,
and deactivating it if required (EOImode == 0).

Signed-off-by : Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 8af943b37a..35bad3953f 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -33,6 +33,7 @@
 
 #define ICC_IAR1_EL1_SPURIOUS0x3ff
 #define VGIC_MAX_SPI 1019
+#define VGIC_MIN_LPI 8192
 
 static int  __vgic_v3_bpr_min(void)
 {
@@ -479,6 +480,137 @@ void handle_iar(struct cpu_user_regs *regs, int regidx, 
const union hsr hsr)
 __vgic_v3_read_iar(regs, regidx, hsr);
 }
 
+static int  __vgic_v3_find_active_lr(int intid, uint64_t *lr_val)
+{
+int i;
+unsigned int used_lrs =  gic_get_num_lrs();
+
+for ( i = 0; i < used_lrs; i++ )
+{
+uint64_t val = gicv3_ich_read_lr(i);
+
+if ( (val & ICH_LR_VIRTUAL_ID_MASK) == intid &&
+(val & ICH_LR_ACTIVE_BIT) )
+{
+*lr_val = val;
+return i;
+}
+}
+
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+return -1;
+}
+
+static int  __vgic_v3_clear_highest_active_priority(void)
+{
+int i;
+uint32_t hap = 0;
+uint8_t nr_apr_regs = vtr_to_nr_apr_regs(READ_SYSREG32(ICH_VTR_EL2));
+
+for ( i = 0; i < nr_apr_regs; i++ )
+{
+uint32_t ap0, ap1;
+int c0, c1;
+
+ap0 = __vgic_v3_read_ap0rn(i);
+ap1 = __vgic_v3_read_ap1rn(i);
+if ( !ap0 && !ap1 )
+{
+hap += 32;
+continue;
+}
+
+c0 = ap0 ? __ffs(ap0) : 32;
+c1 = ap1 ? __ffs(ap1) : 32;
+
+/* Always clear the LSB, which is the highest priority */
+if ( c0 < c1 )
+{
+ap0 &= ~BIT(c0);
+__vgic_v3_write_ap0rn(ap0, i);
+hap += c0;
+}
+else
+{
+ap1 &= ~BIT(c1);
+__vgic_v3_write_ap1rn(ap1, i);
+hap += c1;
+}
+
+/* Rescale to 8 bits of priority */
+return hap << __vgic_v3_bpr_min();
+}
+
+return GICV3_IDLE_PRIORITY;
+}
+
+static void  __vgic_v3_clear_active_lr(int lr, uint64_t lr_val)
+{
+lr_val &= ~ICH_LR_ACTIVE_BIT;
+if ( lr_val & ICH_LR_HW )
+{
+uint32_t pid;
+
+pid = (lr_val & ICH_LR_PHYS_ID_MASK) >> ICH_LR_PHYS_ID_SHIFT;
+WRITE_SYSREG32(pid, ICC_DIR_EL1);
+}
+gicv3_ich_write_lr(lr, lr_val);
+}
+
+static void  __vgic_v3_bump_eoicount(void)
+{
+uint32_t hcr;
+
+hcr = READ_SYSREG32(ICH_HCR_EL2);
+hcr += 1 << ICH_HCR_EOIcount_SHIFT;
+WRITE_SYSREG32(hcr, ICH_HCR_EL2);
+}
+ 
+static void  __vgic_v3_write_eoir(struct cpu_user_regs *regs, int regidx,
+  const union hsr hsr)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+register_t vid = get_user_reg(regs, regidx);
+uint64_t lr_val;
+uint8_t lr_prio, act_prio;
+int lr, grp;
+
+grp = __vgic_v3_get_group(hsr);
+
+/* Drop priority in any case */
+act_prio = __vgic_v3_clear_highest_active_priority();
+
+/* If EOIing an LPI, no deactivate to be performed */
+if ( vid >= VGIC_MIN_LPI )
+return;
+
+/* EOImode == 1, nothing to be done here */
+if ( vmcr & ICH_VMCR_EOIM_MASK )
+return;
+
+lr = __vgic_v3_find_active_lr(vid, _val);
+if ( lr == -1 )
+{
+__vgic_v3_bump_eoicount();
+return;
+}
+
+lr_prio = (lr_val & ICH_LR_PRIORITY_MASK) >> ICH_LR_PRIORITY_SHIFT;
+
+/* If priorities or group do not match, the guest has fscked-up. */
+if ( grp != !!(lr_val & ICH_LR_GROUP) ||
+ __vgic_v3_pri_to_pre(lr_prio, vmcr, grp) != act_prio )
+return;
+
+/* Let's now perform the deactivation */
+__vgic_v3_clear_active_lr(lr, lr_val);
+}
+
+void handle_eoi(struct cpu_user_regs *regs, int regidx, const union hsr hsr)
+{
+__vgic_v3_write_eoir(regs, regidx, hsr);
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = true;
@@ -506,6 +638,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
 handle_iar(regs, regidx, hsr);
 break;
 
+case HSR_SYSREG_ICC_EOIR1_EL1:
+handle_eoi(regs, regidx, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 53d2251840..f9110ebf9c 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -92,6 +92,7 @@
 #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
 #define HSR_SYSREG_ICC_IGRPEN1_E

[Xen-devel] [PATCH v1 05/15] arm64: vgic-v3: Add ICV_IGRPEN1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
f8b630bc542e0368886ae193d3519c832b270359

Add a handler for reading/writing the guest's view of the
ICC_IGRPEN1_EL1
register, which is located in the ICH_VMCR_EL2.VENG1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 364785d3ac..114d5107a9 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -86,6 +86,34 @@ void handle_bpr1(struct cpu_user_regs *regs, int regidx, 
const union hsr hsr)
 __vgic_v3_write_bpr1(regs, regidx);
 }
 
+static void  __vgic_v3_read_igrpen1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+set_user_reg(regs, regidx, !!(vmcr & ICH_VMCR_ENG1_MASK));
+}
+
+static void  __vgic_v3_write_igrpen1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( val & 1 )
+vmcr |= ICH_VMCR_ENG1_MASK;
+else
+vmcr &= ~ICH_VMCR_ENG1_MASK;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+void handle_igrpen1(struct cpu_user_regs *regs, int regidx,
+const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+__vgic_v3_read_igrpen1(regs, regidx);
+else
+__vgic_v3_write_igrpen1(regs, regidx);
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = true;
@@ -105,6 +133,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
  handle_bpr1(regs, regidx, hsr);
  break;
 
+case HSR_SYSREG_ICC_IGRPEN1_EL1:
+handle_igrpen1(regs, regidx, hsr);
+break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 025a27b0b4..731cabc74a 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -90,6 +90,7 @@
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
 #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
+#define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 68a34cc353..ff8bda37d1 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -163,6 +163,8 @@
 #define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
 #define ICH_VMCR_BPR1_SHIFT  18
 #define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
+#define ICH_VMCR_ENG1_SHIFT  1
+#define ICH_VMCR_ENG1_MASK   (1 << ICH_VMCR_ENG1_SHIFT)
 
 #define GICH_LR_VIRTUAL_MASK 0x
 #define GICH_LR_VIRTUAL_SHIFT0
-- 
2.14.1


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

[Xen-devel] [PATCH v1 03/15] arm: Placeholder for handling Group0/1 traps for Cavium Erratum 30115

[Manish Jaggi]

Since this is a SoC errata and trapping of certain group1 registers
should not affect the normal flow. A new file vgic-v3-sr.c is added.

Function vgic_v3_handle_cpuif_access is called from do_trap_guest_sync
if ARM64_WORKAROUND_CAVIUM_30115 capability is found.

A flag skip_hyp_tail is introduced in struct cpu_info. This flag
specifies
that leave_hypervisor_tail not to be called when handling group1 traps
under this errata. enter_hypervisor_head is not invoked when workaround
30115 is in place. enter_hypervisor_head and leave_hypervisor_tail are
invoked in sync, if one is not called other one should be skipped,
otherwise guest vGIC state be out-of-date.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 718fe44455..02cc115239 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -11,3 +11,4 @@ obj-y += smpboot.o
 obj-y += traps.o
 obj-y += vfp.o
 obj-y += vsysreg.o
+obj-$(CONFIG_CAVIUM_ERRATUM_30115) += vgic-v3-sr.o
diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
new file mode 100644
index 00..56b02fd45b
--- /dev/null
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -0,0 +1,56 @@
+/*
+ * xen/arch/arm/arm64/vgic-v3-sr.c
+ *
+ * Code to handle Cavium Erratum 30115
+ *
+ * Manish Jaggi <manish.ja...@cavium.com>
+ * Copyright (c) 2018 Cavium.
+ *
+ * Ths program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
+{
+bool ret = true;
+
+/* Disabling interrupts to prevent change in guest state */
+local_irq_disable();
+if ( hsr.ec != HSR_EC_SYSREG )
+{
+ret = false;
+goto end;
+}
+
+switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
+{
+default:
+ret = false;
+break;
+}
+end:
+local_irq_enable();
+
+return ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
+
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..25778018fb 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2103,6 +2103,27 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
 {
 const union hsr hsr = { .bits = regs->hsr };
 
+if ( check_workaround_30115() )
+{
+bool ret;
+ret  = vgic_v3_handle_cpuif_access(regs, hsr);
+if ( ret )
+{
+   /* if true, g0/g1 vgic register trap is emulated for errata
+* so rest of handling of do_trap_guest_sync is not required.
+*/
+advance_pc(regs, hsr);
+/*
+ * enter_hypervisor_head is not invoked when workaround 30115
+ * is in place. enter_hypervisor_head and leave_hypervisor_tail
+ * are invoked in sync, if one is not called other one should be
+ * skipped, otherwise guest vGIC state be out-of-date.
+ */
+get_cpu_info()->skip_hyp_tail = true;
+return;
+}
+}
+
 enter_hypervisor_head(regs);
 
 switch (hsr.ec) {
@@ -2295,6 +2316,16 @@ void do_trap_fiq(struct cpu_user_regs *regs)
 
 void leave_hypervisor_tail(void)
 {
+/*
+ * if skip_hyp_tail is set simply retrun;
+ */
+if ( unlikely(get_cpu_info()->skip_hyp_tail) )
+{
+/* clear it */
+get_cpu_info()->skip_hyp_tail = false;
+return;
+}
+
 while (1)
 {
 local_irq_disable();
diff --git a/xen/include/asm-arm/arm64/traps.h 
b/xen/include/asm-arm/arm64/traps.h
index 2379b578cb..45fe582abd 100644
--- a/xen/include/asm-arm/arm64/traps.h
+++ b/xen/include/asm-arm/arm64/traps.h
@@ -3,6 +3,9 @@
 
 void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len);
 
+bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs,
+const union hsr hsr);
+
 void do_sysreg(struct cpu_user_regs *regs,
const union hsr hsr);
 
diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index 7a0971fdea..d7b3f4ddb4 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -21,7 +21,8 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu);
 struct cpu_info {
 struct cpu_user_regs guest_cpu_user_regs;
 unsigned long elr;
-unsigned int pad;
+unsigned int pad:31;
+bool skip_hyp_tail:1;
 };
 
 static inline struct c

[Xen-devel] [PATCH v1 08/15] arm64: Add ICV_IAR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
132a324ab62fe4fb8d6dcc2ab4eddb0e93b69afe.

Add a handler for reading the guest's view of the ICC_IAR1_EL1
register. This involves finding the highest priority Group-1
interrupt, checking against both PMR and the active group
priority, activating the interrupt and setting the group
priority as active.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 93ac6f03a9..8af943b37a 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -21,8 +21,18 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
 
 #define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)
+#define vtr_to_nr_apr_regs(v) (1 << (vtr_to_nr_pre_bits(v) - 5))
+
+#define ESR_ELx_SYS64_ISS_CRM_SHIFT 1
+#define ESR_ELx_SYS64_ISS_CRM_MASK (0xf << ESR_ELx_SYS64_ISS_CRM_SHIFT)
+
+#define ICC_IAR1_EL1_SPURIOUS0x3ff
+#define VGIC_MAX_SPI 1019
 
 static int  __vgic_v3_bpr_min(void)
 {
@@ -289,6 +299,186 @@ void gicv3_ich_write_lr(int lr, uint64_t val)
 isb();
 }
 
+static int  __vgic_v3_get_group(const union hsr hsr)
+{
+uint8_t crm = (hsr.bits & ESR_ELx_SYS64_ISS_CRM_MASK) >>
+  ESR_ELx_SYS64_ISS_CRM_SHIFT;
+
+return crm != 8;
+}
+
+unsigned int gic_get_num_lrs(void)
+{
+uint32_t vtr;
+
+vtr = READ_SYSREG32(ICH_VTR_EL2);
+return (vtr & GICH_VTR_NRLRGS) + 1;
+}
+
+static int __vgic_v3_highest_priority_lr(struct cpu_user_regs *regs,
+ uint32_t vmcr, uint64_t *lr_val)
+{
+int i, lr = -1;
+unsigned int used_lrs =  gic_get_num_lrs();
+uint8_t priority = GICV3_IDLE_PRIORITY;
+
+for ( i = 0; i < used_lrs; i++ )
+{
+uint64_t val =  gicv3_ich_read_lr(i);
+uint8_t lr_prio = (val & ICH_LR_PRIORITY_MASK) >> 
ICH_LR_PRIORITY_SHIFT;
+
+/* Not pending in the state? */
+if ( (val & ICH_LR_STATE) != ICH_LR_PENDING_BIT )
+continue;
+
+/* Group-0 interrupt, but Group-0 disabled? */
+if ( !(val & ICH_LR_GROUP) && !(vmcr & ICH_VMCR_ENG0_MASK) )
+continue;
+
+/* Group-1 interrupt, but Group-1 disabled? */
+if ( (val & ICH_LR_GROUP) && !(vmcr & ICH_VMCR_ENG1_MASK) )
+continue;
+
+/* Not the highest priority? */
+if ( lr_prio >= priority )
+continue;
+
+/* This is a candidate */
+priority = lr_prio;
+*lr_val = val;
+lr = i;
+}
+
+if ( lr == -1 )
+*lr_val = ICC_IAR1_EL1_SPURIOUS;
+
+return lr;
+}
+
+static int  __vgic_v3_get_highest_active_priority(void)
+{
+int i;
+uint32_t hap = 0;
+uint8_t nr_apr_regs = vtr_to_nr_apr_regs(READ_SYSREG32(ICH_VTR_EL2));
+
+for ( i = 0; i < nr_apr_regs; i++ )
+{
+uint32_t val;
+
+/*
+ * The ICH_AP0Rn_EL2 and ICH_AP1Rn_EL2 registers
+ * contain the active priority levels for this VCPU
+ * for the maximum number of supported priority
+ * levels, and we return the full priority level only
+ * if the BPR is programmed to its minimum, otherwise
+ * we return a combination of the priority level and
+ * subpriority, as determined by the setting of the
+ * BPR, but without the full subpriority.
+ */
+val  = __vgic_v3_read_ap0rn(i);
+val |= __vgic_v3_read_ap1rn(i);
+if ( !val )
+{
+hap += 32;
+continue;
+}
+
+return (hap + __ffs(val)) << __vgic_v3_bpr_min();
+}
+
+return GICV3_IDLE_PRIORITY;
+}
+
+/*
+ * Convert a priority to a preemption level, taking the relevant BPR
+ * into account by zeroing the sub-priority bits.
+ */
+static uint8_t  __vgic_v3_pri_to_pre(uint8_t pri, uint32_t vmcr, int grp)
+{
+unsigned int bpr;
+
+if ( !grp )
+bpr = __vgic_v3_get_bpr0(vmcr) + 1;
+else
+bpr = __vgic_v3_get_bpr1(vmcr);
+
+return pri & (GENMASK(7, 0) << bpr);
+}
+
+/*
+ * The priority value is independent of any of the BPR values, so we
+ * normalize it using the minumal BPR value. This guarantees that no
+ * matter what the guest does with its BPR, we can always set/get the
+ * same value of a priority.
+ */
+static void  __vgic_v3_set_active_priority(uint8_t pri, uint32_t vmcr, int grp)
+{
+uint8_t pre, ap;
+uint32_t val;
+int apr;
+
+pre = __vgic_v3_pri_to_pre(pri, vmcr, grp);
+ap = pre >> __vgic_v3_bpr_min();
+apr = ap / 32;
+
+if ( !grp )
+{
+val = __vgic_v3_read_ap0rn(apr);
+__vgic_v3_write_ap0rn(val | BIT(ap % 32), apr);
+}
+else
+{
+val = __vgic_v3_read_ap1rn(apr);
+__vgic_v3_write_ap1rn(val | BIT(ap % 32), apr);
+}
+}
+
+static void  __vgic_v3_read_iar(struct cpu_user_regs *reg

[Xen-devel] [PATCH v1 11/15] arm64: vgic-v3: Add ICV_BPR0_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
423de85a98c2b50715a0784a74f6124fbc0b1548

Add a handler for reading/writing the guest's view of the ICC_BPR0_EL1
register, which is located in the ICH_VMCR_EL2.BPR0 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 537e164062..e79a56619d 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -97,6 +97,41 @@ void handle_bpr1(struct cpu_user_regs *regs, int regidx, 
const union hsr hsr)
 __vgic_v3_write_bpr1(regs, regidx);
 }
 
+static void  __vgic_v3_read_bpr0(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+set_user_reg(regs, regidx, __vgic_v3_get_bpr0(vmcr));
+}
+
+static void  __vgic_v3_write_bpr0(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = __vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR0_SHIFT;
+val &= ICH_VMCR_BPR0_MASK;
+vmcr &= ~ICH_VMCR_BPR0_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+void handle_bpr0(struct cpu_user_regs *regs, int regidx, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+__vgic_v3_read_bpr0(regs, regidx);
+else
+__vgic_v3_write_bpr0(regs, regidx);
+}
+
 static void  __vgic_v3_read_igrpen1(struct cpu_user_regs *regs, int regidx)
 {
 uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
@@ -646,6 +681,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
 
 switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
 {
+case HSR_SYSREG_ICC_BPR0_EL1:
+ handle_bpr0(regs, regidx, hsr);
+ break;
+
 case HSR_SYSREG_ICC_BPR1_EL1:
  handle_bpr1(regs, regidx, hsr);
  break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index c23c4a33b2..ef01576b01 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -94,6 +94,7 @@
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
+#define HSR_SYSREG_ICC_BPR0_EL1  HSR_SYSREG(3,0,c12,c8,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
-- 
2.14.1


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

[Xen-devel] [PATCH v1 12/15] arm64: vgic-v3: Add ICV_IGNREN0_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit:
fbc48a0011deb3d51cb657ca9c0f9083f41c0665

Add a handler for reading/writing the guest's view of the
ICC_IGRPEN0_EL1 register, which is located in the ICH_VMCR_EL2.VENG0
field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index e79a56619d..8951a75481 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -160,6 +160,34 @@ void handle_igrpen1(struct cpu_user_regs *regs, int regidx,
 __vgic_v3_write_igrpen1(regs, regidx);
 }
 
+static void  __vgic_v3_read_igrpen0(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+set_user_reg(regs, regidx, !!(vmcr & ICH_VMCR_ENG0_MASK));
+}
+
+static void  __vgic_v3_write_igrpen0(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( val & 1 )
+vmcr |= ICH_VMCR_ENG0_MASK;
+else
+vmcr &= ~ICH_VMCR_ENG0_MASK;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+void handle_igrpen0(struct cpu_user_regs *regs, int regidx,
+const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+__vgic_v3_read_igrpen0(regs, regidx);
+else
+__vgic_v3_write_igrpen0(regs, regidx);
+}
+
 void  __vgic_v3_write_ap0rn(uint32_t val, int n)
 {
 switch (n)
@@ -689,6 +717,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
  handle_bpr1(regs, regidx, hsr);
  break;
 
+case HSR_SYSREG_ICC_IGRPEN0_EL1:
+handle_igrpen0(regs, regidx, hsr);
+break;
+
 case HSR_SYSREG_ICC_IGRPEN1_EL1:
 handle_igrpen1(regs, regidx, hsr);
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index ef01576b01..f9049a6b04 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -91,6 +91,7 @@
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
 #define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
 #define HSR_SYSREG_ICC_IGRPEN1_EL1 HSR_SYSREG(3,0,c12,c12,7)
+#define HSR_SYSREG_ICC_IGRPEN0_EL1 HSR_SYSREG(3,0,c12,c12,6)
 #define HSR_SYSREG_ICC_IAR1_EL1   HSR_SYSREG(3,0,c12,c12,0)
 #define HSR_SYSREG_ICC_EOIR1_EL1  HSR_SYSREG(3,0,c12,c12,1)
 #define HSR_SYSREG_ICC_HPPIR1_EL1 HSR_SYSREG(3,0,c12,c12,2)
-- 
2.14.1


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

[Xen-devel] [PATCH v1 04/15] arm64: vgic-v3: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 56b02fd45b..364785d3ac 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -20,10 +20,76 @@
 #include 
 #include 
 #include 
+#include 
+
+#define vtr_to_nr_pre_bits(v) uint32_t)(v) >> 26) & 7) + 1)
+
+static int  __vgic_v3_bpr_min(void)
+{
+/* See Pseudocode for VPriorityGroup */
+return 8 - vtr_to_nr_pre_bits(READ_SYSREG32(ICH_VTR_EL2));
+}
+
+static unsigned int __vgic_v3_get_bpr0(uint32_t vmcr)
+{
+return (vmcr & ICH_VMCR_BPR0_MASK) >> ICH_VMCR_BPR0_SHIFT;
+}
+
+static unsigned int __vgic_v3_get_bpr1(uint32_t vmcr)
+{
+unsigned int bpr;
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+{
+bpr = __vgic_v3_get_bpr0(vmcr);
+if ( bpr < 7 )
+bpr++;
+}
+else
+bpr = (vmcr & ICH_VMCR_BPR1_MASK) >> ICH_VMCR_BPR1_SHIFT;
+
+return bpr;
+}
+
+static void  __vgic_v3_read_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+set_user_reg(regs, regidx, __vgic_v3_get_bpr1(vmcr));
+}
+
+static void  __vgic_v3_write_bpr1(struct cpu_user_regs *regs, int regidx)
+{
+register_t val = get_user_reg(regs, regidx);
+uint8_t bpr_min = __vgic_v3_bpr_min();
+uint32_t vmcr = READ_SYSREG32(ICH_VMCR_EL2);
+
+if ( vmcr & ICH_VMCR_CBPR_MASK )
+return;
+
+/* Enforce BPR limiting */
+if ( val < bpr_min )
+val = bpr_min;
+
+val <<= ICH_VMCR_BPR1_SHIFT;
+val &= ICH_VMCR_BPR1_MASK;
+vmcr &= ~ICH_VMCR_BPR1_MASK;
+vmcr |= val;
+
+WRITE_SYSREG32(vmcr, ICH_VMCR_EL2);
+}
+
+void handle_bpr1(struct cpu_user_regs *regs, int regidx, const union hsr hsr)
+{
+if ( hsr.sysreg.read )
+__vgic_v3_read_bpr1(regs, regidx);
+else
+__vgic_v3_write_bpr1(regs, regidx);
+}
 
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = true;
+int regidx = hsr.sysreg.reg;
 
 /* Disabling interrupts to prevent change in guest state */
 local_irq_disable();
@@ -35,6 +101,10 @@ bool vgic_v3_handle_cpuif_access(struct cpu_user_regs 
*regs, const union hsr hsr
 
 switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
 {
+case HSR_SYSREG_ICC_BPR1_EL1:
+ handle_bpr1(regs, regidx, hsr);
+ break;
+
 default:
 ret = false;
 break;
diff --git a/xen/include/asm-arm/arm64/sysregs.h 
b/xen/include/asm-arm/arm64/sysregs.h
index 084d2a1e5d..025a27b0b4 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -89,6 +89,7 @@
 #define HSR_SYSREG_ICC_ASGI1R_EL1 HSR_SYSREG(3,1,c12,c11,6)
 #define HSR_SYSREG_ICC_SGI0R_EL1  HSR_SYSREG(3,2,c12,c11,7)
 #define HSR_SYSREG_ICC_SRE_EL1HSR_SYSREG(3,0,c12,c12,5)
+#define HSR_SYSREG_ICC_BPR1_EL1   HSR_SYSREG(3,0,c12,c12,3)
 #define HSR_SYSREG_CONTEXTIDR_EL1 HSR_SYSREG(3,0,c13,c0,1)
 
 #define HSR_SYSREG_PMCR_EL0   HSR_SYSREG(3,3,c9,c12,0)
diff --git a/xen/include/asm-arm/gic_v3_defs.h 
b/xen/include/asm-arm/gic_v3_defs.h
index 65c9dc47cf..68a34cc353 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -157,6 +157,12 @@
 
 #define GICH_VMCR_EOI(1 << 9)
 #define GICH_VMCR_VENG1  (1 << 1)
+#define ICH_VMCR_CBPR_SHIFT  4
+#define ICH_VMCR_CBPR_MASK   (1 << ICH_VMCR_CBPR_SHIFT)
+#define ICH_VMCR_BPR0_SHIFT  21
+#define ICH_VMCR_BPR0_MASK   (7 << ICH_VMCR_BPR0_SHIFT)
+#define ICH_VMCR_BPR1_SHIFT  18
+#define ICH_VMCR_BPR1_MASK   (7 << ICH_VMCR_BPR1_SHIFT)
 
 #define GICH_LR_VIRTUAL_MASK 0x
 #define GICH_LR_VIRTUAL_SHIFT0
-- 
2.14.1


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

[Xen-devel] [PATCH v1 06/15] arm64: Add accessors for the ICH_APxRn_EL2 registers

[Manish Jaggi]

This patch is ported to xen from linux commit
63000dd8006dc987db31ba670edc23142ea91e01

As we're about to access the Active Priority registers a lot more,
let's define accessors that take the register number as a parameter.

This patch only has accessors, another patch will have register trap handlers

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/arch/arm/arm64/vgic-v3-sr.c b/xen/arch/arm/arm64/vgic-v3-sr.c
index 114d5107a9..1aaade40dc 100644
--- a/xen/arch/arm/arm64/vgic-v3-sr.c
+++ b/xen/arch/arm/arm64/vgic-v3-sr.c
@@ -114,6 +114,98 @@ void handle_igrpen1(struct cpu_user_regs *regs, int regidx,
 __vgic_v3_write_igrpen1(regs, regidx);
 }
 
+void  __vgic_v3_write_ap0rn(uint32_t val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP0R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP0R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP0R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+void __vgic_v3_write_ap1rn(uint32_t val, int n)
+{
+switch (n)
+{
+case 0:
+WRITE_SYSREG32(val, ICH_AP1R0_EL2);
+break;
+case 1:
+WRITE_SYSREG32(val, ICH_AP1R1_EL2);
+break;
+case 2:
+WRITE_SYSREG32(val, ICH_AP1R2_EL2);
+break;
+case 3:
+WRITE_SYSREG32(val, ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+}
+
+uint32_t  __vgic_v3_read_ap0rn(int n)
+{
+uint32_t val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP0R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP0R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP0R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP0R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
+uint32_t  __vgic_v3_read_ap1rn(int n)
+{
+uint32_t val;
+
+switch (n)
+{
+case 0:
+val = READ_SYSREG32(ICH_AP1R0_EL2);
+break;
+case 1:
+val = READ_SYSREG32(ICH_AP1R1_EL2);
+break;
+case 2:
+val = READ_SYSREG32(ICH_AP1R2_EL2);
+break;
+case 3:
+val = READ_SYSREG32(ICH_AP1R3_EL2);
+break;
+default:
+unreachable();
+}
+
+return val;
+}
+
 bool vgic_v3_handle_cpuif_access(struct cpu_user_regs *regs, const union hsr 
hsr)
 {
 bool ret = true;
-- 
2.14.1


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

[Xen-devel] [PATCH v1 02/15] arm64: Add config for Cavium Thunder erratum 30115

[Manish Jaggi]

Some Cavium Thunder CPUs suffer a problem where a Xen guest may
inadvertently cause the host kernel to quit receiving interrupts.
This patch adds CONFIG_CAVIUM_ERRATUM_30115. Subsequent patches will
provide workaround.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index c9854c39f4..a2546d4bb5 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -48,3 +48,4 @@ stable hypervisors.
 | ARM| Cortex-A57  | #852523 | N/A 
|
 | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
 | ARM| Cortex-A57  | #834220 | ARM64_ERRATUM_834220
|
+| CAVIUM | ThunderX1   | #30115  | CAVIUM_ERRATUM_30115
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index f58019d6ed..762b761f7d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -169,6 +169,17 @@ config ARM64_ERRATUM_834220
 
  If unsure, say Y.
 
+config CAVIUM_ERRATUM_30115
+   bool "Cavium Erratum 30115"
+   depends on HAS_GICV3
+   help
+ On ThunderX T88 pass 1.x through 2.2, T81 pass 1.0 through
+ 1.2, and T83 Pass 1.0, guest execution may disable
+ interrupts in host. Trapping both GICv3 group-0 and group-1
+ accesses sidesteps the issue.
+
+ If unsure, say Y.
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index fe9e9facbe..d49698f785 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -56,6 +56,27 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
(1 << MIDR_VARIANT_SHIFT) | 2),
 },
+#endif
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+{
+/* Cavium ThunderX, T88 pass 1.x - 2.2 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+{
+/* Cavium ThunderX, T81 pass 1.0 - 1.2 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX_81XX, 0x00, 0x02),
+},
+{
+/* Cavium ThunderX, T83 pass 1.0 */
+.desc = "Cavium erratum 30115",
+.capability = ARM64_WORKAROUND_CAVIUM_30115,
+MIDR_RANGE(MIDR_THUNDERX_83XX, 0x00, 0x00),
+},
 #endif
 {},
 };
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 8b158429c7..521f03521b 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -41,6 +41,7 @@ static inline bool check_workaround_##erratum(void)   
  \
 
 CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
 CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
+CHECK_WORKAROUND_HELPER(30115, ARM64_WORKAROUND_CAVIUM_30115, CONFIG_ARM_64)
 
 #undef CHECK_WORKAROUND_HELPER
 
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index f00b6dbd39..d409636bf0 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -42,8 +42,9 @@
 #define LIVEPATCH_FEATURE   4
 #define SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT 5
 #define SKIP_CTXT_SWITCH_SERROR_SYNC 6
+#define ARM64_WORKAROUND_CAVIUM_30115 7
 
-#define ARM_NCAPS   7
+#define ARM_NCAPS   8
 
 #ifndef __ASSEMBLY__
 
-- 
2.14.1


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

[Xen-devel] [PATCH v1 01/15] arm64: cputype: Add MIDR values for Cavium ThunderX1 CPU family

[Manish Jaggi]

Add MIDR values for Cavium ThunderX1 SoC family.
ThunderX1, 81XX, 83XX.

Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 65eb1071e1..62ad244785 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -43,15 +43,24 @@
 })
 
 #define ARM_CPU_IMP_ARM 0x41
+#define ARM_CPU_IMP_CAVIUM  0x43
 
 #define ARM_CPU_PART_CORTEX_A15 0xC0F
 #define ARM_CPU_PART_CORTEX_A53 0xD03
 #define ARM_CPU_PART_CORTEX_A57 0xD07
 
+#define CAVIUM_CPU_PART_THUNDERX  0x0A1
+#define CAVIUM_CPU_PART_THUNDERX_81XX 0x0A2
+#define CAVIUM_CPU_PART_THUNDERX_83XX 0x0A3
+
 #define MIDR_CORTEX_A15 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A15)
 #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A53)
 #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, 
ARM_CPU_PART_CORTEX_A57)
 
+#define MIDR_THUNDERX  MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX)
+#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_THUNDERX_83XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, 
CAVIUM_CPU_PART_THUNDERX_83XX)
+
 /* MPIDR Multiprocessor Affinity Register */
 #define _MPIDR_UP   (30)
 #define MPIDR_UP(_AC(1,U) << _MPIDR_UP)
-- 
2.14.1


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

Re: [Xen-devel] [PATCH 01/12] arm:Kconfig Rename menu text

[Manish Jaggi]

Hi Julien,

On 03/13/2018 05:45 PM, Julien Grall wrote:

Hi,

On 12/03/18 12:42, mja...@caviumnetworks.com wrote:

From: Manish Jaggi <manish.ja...@cavium.com>

Rename the menu text to Errata Workarounds. Subsequent patches will
add config options for SoC specific erratas.


Well, your SoC is an Arm SoC, right? So what is the benefits of this 
new name? M

It was based on your last comment

"I would much prefer to see the memu "ARM errata workaround via..." 
renamed to "Errata Workarounds". So we have only one menu with all 
workarounds."




ore that it still depends on HAS_ALTERNATIVE.

check_workaroundXXX depends on it. So I kept it as is.

If you think this patch is not required, I can drop it.

Cheers,



Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index f58019d6ed..10a6d1a956 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -59,7 +59,7 @@ config SBSA_VUART_CONSOLE
    endmenu
  -menu "ARM errata workaround via the alternative framework"
+menu "Errata workarounds"
  depends on HAS_ALTERNATIVE >
  config ARM64_ERRATUM_827319






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

Re: [Xen-devel] [PATCH 00/13] acpi: arm: Add IORT Support

[Manish Jaggi]

On 03/13/2018 08:09 PM, Julien Grall wrote:

Hi,

I got duplicated e-mails on my inbox for this series. Each version 
have a different series and all in the same threading.


I have no idea which emails to answer properly. So please do a proper 
resend of this series and this time with my correct e-mail address.



sent to Julien Grall <julien.gr...@arm.com> this time.

Cheers,

On 12/03/18 07:49, mja...@caviumnetworks.com wrote:

From: Manish Jaggi <mja...@caviumnetworks.com>

This patch aims to add the support of IORT in Xen. Below is the list
of major components which this patchset provides.
a. Add support for parsing the IORT
b. Provides API to populate/query requesterid - streamID mappings and
    reuqesterid - deviceid mappings
c. The requesterid - deviceid mappings is used to create the IORT for
    hardware domain (which hides smmu nodes from IORT)
d. iort.c fwnode.h fwspec code is imported from linux and modified.

Changes since RFC
- Added more documentation
- Moved code to arch/arm/acpi/ folder
- Lot of fixes for review comments

This patch works with [1] but few modifiations were made
(a) path of acpi_iort.h has changed so fixed to asm/acpi/acpi_iort.h
(b) Macro #define alloc_io_pgtable_ops(f, c, o) in Patch 5 of [1] 
results in

  -ENOMEM and need to be fixed.

-[1] 
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00713.html


Manish Jaggi (13):
   acpi: arm: API: Populate/query rid-devid rid-sid map.
   acpi: arm: query estimated size of hardware domain's IORT.
   acpi: arm: Code to generate Hardware Domains IORT
   acpi: arm: Copy fwnode / iommu_fwspec code from Linux 4.14
   acpi: arm: Import acpi_iort.h verbatim from linux 4.14
   acpi: arm: Update acpi_iort.h with xen specific changes
   arm: Adding ACPI_IORT in arm Kconfig
   asm: arm: pci: Fix the #include label in asm-arm/pci.h
   asm: arm: to_pci_dev
   asm: arm: add dev_is_pci
   asm: arm: add pci_domain_nr
   acpi: arm: Provide support for iort iommu configuration hooks
   acpi: arm: Add code to parse IORT and prepare rid maps.

  xen/arch/arm/Kconfig |   4 +
  xen/arch/arm/acpi/Makefile   |   3 +
  xen/arch/arm/acpi/gen-iort.c | 400 +++
  xen/arch/arm/acpi/iort.c | 608 
+++

  xen/arch/arm/acpi/ridmap.c   | 126 
  xen/arch/arm/domain_build.c  |  51 ++-
  xen/drivers/passthrough/arm/iommu.c  |  85 +
  xen/drivers/passthrough/arm/smmu.c   |   3 +-
  xen/include/asm-arm/acpi.h   |   1 +
  xen/include/asm-arm/acpi/acpi_iort.h |  51 +++
  xen/include/asm-arm/acpi/gen-iort.h  |  44 +++
  xen/include/asm-arm/acpi/ridmap.h    | 112 +++
  xen/include/asm-arm/device.h |  17 +-
  xen/include/asm-arm/fwnode.h | 128 
  xen/include/asm-arm/fwspec.h |  38 +++
  xen/include/asm-arm/pci.h    |  12 +-
  xen/include/xen/pci.h    |   2 +
  17 files changed, 1675 insertions(+), 10 deletions(-)
  create mode 100644 xen/arch/arm/acpi/gen-iort.c
  create mode 100644 xen/arch/arm/acpi/iort.c
  create mode 100644 xen/arch/arm/acpi/ridmap.c
  create mode 100644 xen/include/asm-arm/acpi/acpi_iort.h
  create mode 100644 xen/include/asm-arm/acpi/gen-iort.h
  create mode 100644 xen/include/asm-arm/acpi/ridmap.h
  create mode 100644 xen/include/asm-arm/fwnode.h
  create mode 100644 xen/include/asm-arm/fwspec.h






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

Re: [Xen-devel] [PATCH 5/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

On 10 March 2018 at 23:23, Manish Jaggi <mja...@caviumnetworks.com> wrote:
> Hi Sameer,
>
>
>
> On 02/09/2018 08:40 AM, Sameer Goel wrote:
>>
>> This driver follows an approach similar to smmu driver. The intent here
>> is to reuse as much Linux code as possible.
>> - Glue code has been introduced to bridge the API calls.
>> - Called Linux functions from the Xen IOMMU function calls.
>> - Xen modifications are preceded by /*Xen: comment */
>> - xen/linux_compat: Add a Linux compat header
>>For porting files directly from Linux it is useful to have a function
>> mapping
>>definitions from Linux to Xen. This file adds common API functions and
>>other defines that are needed for porting arm SMMU drivers.
>>
>> Signed-off-by: Sameer Goel <sameer.g...@linaro.org>
>> ---
>>   xen/arch/arm/p2m.c|   1 +
>>   xen/drivers/Kconfig   |   2 +
>>   xen/drivers/passthrough/arm/Kconfig   |   8 +
>>   xen/drivers/passthrough/arm/Makefile  |   1 +
>>   xen/drivers/passthrough/arm/smmu-v3.c | 892
>> --
>>   xen/include/xen/linux_compat.h|  84 
>>   6 files changed, 959 insertions(+), 29 deletions(-)
>>   create mode 100644 xen/drivers/passthrough/arm/Kconfig
>>   create mode 100644 xen/include/xen/linux_compat.h
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 65e8b9c6ea..fef7605fd6 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -1460,6 +1460,7 @@ err:
>>   static void __init setup_virt_paging_one(void *data)
>>   {
>>   unsigned long val = (unsigned long)data;
>> +/* SMMUv3 S2 cfg vtcr reuses the following value */
>>   WRITE_SYSREG32(val, VTCR_EL2);
>>   isb();
>>   }
>> diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
>> index bc3a54f0ea..612655386d 100644
>> --- a/xen/drivers/Kconfig
>> +++ b/xen/drivers/Kconfig
>> @@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
>> source "drivers/video/Kconfig"
>>   +source "drivers/passthrough/arm/Kconfig"
>> +
>>   endmenu
>> diff --git a/xen/drivers/passthrough/arm/Kconfig
>> b/xen/drivers/passthrough/arm/Kconfig
>> new file mode 100644
>> index 00..cda899f608
>> --- /dev/null
>> +++ b/xen/drivers/passthrough/arm/Kconfig
>> @@ -0,0 +1,8 @@
>> +
>> +config ARM_SMMU_v3
>> +   bool "ARM SMMUv3 Support"
>> +   depends on ARM_64
>> +   help
>> +Support for implementations of the ARM System MMU architecture
>> +version 3.
>> +
>> diff --git a/xen/drivers/passthrough/arm/Makefile
>> b/xen/drivers/passthrough/arm/Makefile
>> index f4cd26e15d..e14732b55c 100644
>> --- a/xen/drivers/passthrough/arm/Makefile
>> +++ b/xen/drivers/passthrough/arm/Makefile
>> @@ -1,2 +1,3 @@
>>   obj-y += iommu.o
>>   obj-y += smmu.o
>> +obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
>> diff --git a/xen/drivers/passthrough/arm/smmu-v3.c
>> b/xen/drivers/passthrough/arm/smmu-v3.c
>> index e67ba6c40f..f43485fe6e 100644
>> --- a/xen/drivers/passthrough/arm/smmu-v3.c
>> +++ b/xen/drivers/passthrough/arm/smmu-v3.c
>> @@ -18,28 +18,414 @@
>>* Author: Will Deacon <will.dea...@arm.com>
>>*
>>* This driver is powered by bad coffee and bombay mix.
>> + *
>> + *
>> + * Based on Linux drivers/iommu/arm-smmu-v3.c
>> + * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
>> + *
>> + * Xen modifications:
>> + * Sameer Goel <sameer.g...@linaro.org>
>> + * Copyright (C) 2017, The Linux Foundation, All rights reserved.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* Alias to Xen device tree helpers */
>> +#define device_node dt_device_node
>> +#define of_phandle_args dt_phandle_args
>> +#define of_device_id dt_device_match
>> +#define of_match_node dt_match_node
>> +#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np,
>> pname, out))
>> +#define of_property_read_bool dt_property_read_bool
>> +#define of_parse_phandle_with_args dt_parse_phandle_with_args
>> +
>> +/* X

Re: [Xen-devel] [PATCH 5/7] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Manish Jaggi]

Hi Sameer,


On 02/09/2018 08:40 AM, Sameer Goel wrote:

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- xen/linux_compat: Add a Linux compat header
   For porting files directly from Linux it is useful to have a function mapping
   definitions from Linux to Xen. This file adds common API functions and
   other defines that are needed for porting arm SMMU drivers.

Signed-off-by: Sameer Goel 
---
  xen/arch/arm/p2m.c|   1 +
  xen/drivers/Kconfig   |   2 +
  xen/drivers/passthrough/arm/Kconfig   |   8 +
  xen/drivers/passthrough/arm/Makefile  |   1 +
  xen/drivers/passthrough/arm/smmu-v3.c | 892 --
  xen/include/xen/linux_compat.h|  84 
  6 files changed, 959 insertions(+), 29 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/Kconfig
  create mode 100644 xen/include/xen/linux_compat.h

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 65e8b9c6ea..fef7605fd6 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1460,6 +1460,7 @@ err:
  static void __init setup_virt_paging_one(void *data)
  {
  unsigned long val = (unsigned long)data;
+/* SMMUv3 S2 cfg vtcr reuses the following value */
  WRITE_SYSREG32(val, VTCR_EL2);
  isb();
  }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index bc3a54f0ea..612655386d 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
  
  source "drivers/video/Kconfig"
  
+source "drivers/passthrough/arm/Kconfig"

+
  endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
  obj-y += iommu.o
  obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..f43485fe6e 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,414 @@
   * Author: Will Deacon 
   *
   * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if (pdev->type == DEV_ACPI) {
+   ret = 1;
+   iort_node = pdev->acpi_node;
+   node_smmu_data =
+   (struct acpi_iort_smmu_v3 
*)iort_node->node_data;
+
+   if (node_smmu_data != NULL) {
+   

Re: [Xen-devel] [RFC 06/11] fwnode xen spacific changes

[Manish Jaggi]

Hi Julien,


On 01/19/2018 12:21 AM, Julien Grall wrote:

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8efd..f78482ca0c 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -6,6 +6,8 @@
  enum device_type
  {
  DEV_DT,
+    DEV_ACPI,


You don't use DEV_ACPI in this patch. So why is there?


+    DEV_PCI,
  };
    struct dev_archdata {
@@ -18,8 +20,13 @@ struct device
  enum device_type type;
  #ifdef CONFIG_HAS_DEVICE_TREE
  struct dt_device_node *of_node; /* Used by drivers imported 
from Linux */


As said on Sameer's patches, I was expecting a todo in the code after 
the discussion about leave of_node here. 

I think you are referring to https://patchwork.kernel.org/patch/9963109/
Could you please add what TODO you wish to add ?

I could not find  any discussion on of_node in the mail chain


-Regards
Manish

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

Re: [Xen-devel] [RFC 06/11] fwnode xen spacific changes

[Manish Jaggi]

Hi Julien,


On 01/19/2018 12:21 AM, Julien Grall wrote:

diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index 6734ae8efd..f78482ca0c 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -6,6 +6,8 @@
  enum device_type
  {
  DEV_DT,
+    DEV_ACPI,


You don't use DEV_ACPI in this patch. So why is there?


+    DEV_PCI,
  };
    struct dev_archdata {
@@ -18,8 +20,13 @@ struct device
  enum device_type type;
  #ifdef CONFIG_HAS_DEVICE_TREE
  struct dt_device_node *of_node; /* Used by drivers imported 
from Linux */


As said on Sameer's patches, I was expecting a todo in the code after 
the discussion about leave of_node here. 

I think you are referring to https://patchwork.kernel.org/patch/9963109/
Could you please add what TODO you wish to add ?

I could not find  any discussion on of_node in the mail chain


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

Re: [Xen-devel] [PATCH 0/7] SMMUv3 driver

[Manish Jaggi]

On 03/01/2018 08:05 PM, Julien Grall wrote:

Hi,

On 09/02/18 03:10, Sameer Goel wrote:
This patch set adds support for the SMMUv3 driver. This is a 
continuation on

a RFCv4.[1]
The IORT support came from [2]. This RFC has some conflicting defines 
that
have to be addressed by introducing the linux_compat.h header in IORT 
patch

set. In any case the SMMU changes apply on top of IORT patches.


The SMMUv3 series looks in good state and I would like to see this 
merged for Xen 4.11. Manish, do we have an update on the IORT side?

Started merging this series with my code.


Cheers,



List of changes:
- Addition of a linux_compat header.
- Addition of a common header for arm smmu defines.
- Rebase of the SMMUv3 driver to the driver in linux kernel 4.14 rc7.
- New config defines for ARM SMMU drivers.

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-12/msg01294.html
[2] 
https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg7.html

Sameer Goel (7):
   Port WARN_ON_ONCE() from Linux
   xen/bitops: Rename LOG_2 to ilog2
   passthrough/arm: Modify SMMU driver to use generic device definition
   Add verbatim copy of arm-smmu-v3.c from Linux
   xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
   drivers/passthrough/arm: Refactor code for arm smmu drivers
   xen/smmu: Add a new config define for legacy SMMU

  xen/arch/arm/p2m.c |    1 +
  xen/arch/arm/xen.lds.S |    1 +
  xen/arch/x86/x86_64/asm-offsets.c  |    2 +-
  xen/arch/x86/xen.lds.S |    1 +
  xen/drivers/Kconfig    |    2 +
  xen/drivers/passthrough/arm/Kconfig    |   14 +
  xen/drivers/passthrough/arm/Makefile   |    3 +-
  xen/drivers/passthrough/arm/arm_smmu.h |  125 ++
  xen/drivers/passthrough/arm/smmu-v3.c  | 3625 


  xen/drivers/passthrough/arm/smmu.c |  114 +-
  xen/include/xen/bitops.h   |    2 +-
  xen/include/xen/lib.h  |   13 +
  xen/include/xen/linux_compat.h |   84 +
  13 files changed, 3877 insertions(+), 110 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/Kconfig
  create mode 100644 xen/drivers/passthrough/arm/arm_smmu.h
  create mode 100644 xen/drivers/passthrough/arm/smmu-v3.c
  create mode 100644 xen/include/xen/linux_compat.h






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

Re: [Xen-devel] [RFC PATCH 02/10] arm64: Add hook to handle guest GICv3 sysreg accesses

[Manish Jaggi]

On 02/26/2018 12:12 PM, Manish Jaggi wrote:



On 02/01/2018 04:24 PM, Julien Grall wrote:

Hi Manish,

On 01/02/18 08:51, Manish Jaggi wrote:

On 01/25/2018 11:37 PM, Julien Grall wrote:

Hi,

I forgot to mention one thing about the placement of 
do_fixup_vgic_errata.


On 16/01/18 15:42, mja...@caviumnetworks.com wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..d4f0581d33 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2103,6 +2103,17 @@ void do_trap_guest_sync(struct 
cpu_user_regs *regs)

  {
  const union hsr hsr = { .bits = regs->hsr };
  +#ifdef CONFIG_VGIC_ERRATA
+    int ret;
+
+    ret  = do_fixup_vgic_errata(regs,hsr);
+    if ( !ret )
+    {
+    advance_pc(regs, hsr);
+    return;


I am fully aware that I suggested this solution and still support 
that the vGIC errata should be fully separated. After all, it deals 
with hardware bug and the errata will just update the LRs as the 
hardware would do.


enter_hypervisor_head() will sync the LRs state to the internal 
vGIC state. leave_hypervisor_head() will process pending softirq 
and write/update the LRs based on the internal vGIC state.


As you rightfully did, the do_fixup_vgic_errata should be called 
before syncing the LRs. However, even if you return early here, you 
will still execute leave_hypervisor_tail(). This mean that pending 
softirqs will be processed and potentially the vCPU rescheduled. 
Because the LRs were not synced (enter_hypervisor_head()) was not 
called, then the vGIC state will not out-of-date and would lead to 
all sort of potential issues.


As the vGIC errata implies trapping the register such as IAR1 
(reading interrupt), we want to get a fastpath for it (e.g not 
trying to execute softirq...). So I think we should bypass 
leave_hypervisor_tail(). I am not entirely sure how to do it nicely 
thought.




How about adding a check for group1_trap enable in 
leave_hypervisor_tail().


void leave_hypervisor_tail(void)
{
+if (group1_trap)
+   return;


I guess you mean the variable you introduced in patch #10. In that 
case, this would be totally wrong. You only want to skip 
leave_hypervisor_tail() when you are handling a ICV_* System registers.


What you want is adding a bool in the structure cpu_info to tell 
whether leave_hypervisor_tail() should be skipped.



Why would it be wrong? I don't follow our point.
Also adding a flag in cpu_info would be overkill, use of a global 
variable is simpler.

I am planning to remove group1_trap as a command line, and use it as

static void gicv3_hyp_init(void)
{
...
#ifdef CONFIG_CAVIUM_ERRATUM_30115
    if (cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_30115))
    group1_trap = 1;
#endif
...
}

Attaching test patch

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 473e26111f..581c07b274 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -64,6 +64,7 @@ static DEFINE_PER_CPU(void __iomem*, rbase);
 #define GICD   (gicv3.map_dbase)
 #define GICD_RDIST_BASE    (this_cpu(rbase))
 #define GICD_RDIST_SGI_BASE    (GICD_RDIST_BASE + SZ_64K)
+static bool group1_trap = 0;

 /*
  * Saves all 16(Max) LR registers. Though number of LRs implemented
@@ -825,7 +826,7 @@ static void gicv3_cpu_disable(void)

 static void gicv3_hyp_init(void)
 {
-    uint32_t vtr;
+    uint32_t vtr, reg32;

 vtr = READ_SYSREG32(ICH_VTR_EL2);
 gicv3_info.nr_lrs  = (vtr & GICH_VTR_NRLRGS) + 1;
@@ -837,6 +838,10 @@ static void gicv3_hyp_init(void)

 WRITE_SYSREG32(GICH_VMCR_EOI | GICH_VMCR_VENG1, ICH_VMCR_EL2);
 WRITE_SYSREG32(GICH_HCR_EN, ICH_HCR_EL2);
+
+    reg32 = GICH_HCR_EN;
+    reg32 |= (group1_trap) ? GICH_HCR_TALL1 : 0;
+    WRITE_SYSREG32(reg32, ICH_HCR_EL2);
 }

 /* Set up the per-CPU parts of the GIC for a secondary CPU */
@@ -1651,6 +1656,11 @@ static int __init gicv3_init(void)
 return -ENODEV;
 }

+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+    if (cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_30115))
+    group1_trap = 1;
+#endif
+
 if ( acpi_disabled )
 gicv3_dt_init();
 else
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..dbee0c322f 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2295,6 +2295,10 @@ void do_trap_fiq(struct cpu_user_regs *regs)

 void leave_hypervisor_tail(void)
 {
+#ifdef CONFIG_CAVIUM_ERRATUM_30115
+    if (cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_30115))
+    return;
+#endif
 while (1)
 {
 local_irq_disable();
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index d3d7bda50d..e4c77fefd6 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -117,6 +117,7 @@
 #define GICH_HCR_VGRP0DIE (1 << 5)
 #define GICH_HCR_VGRP1EIE (1 << 6)
 #define GICH_HCR_VGRP1DIE (1 << 7)
+#define GICH_HCR_TALL1    (1 << 12)

 #define GICH_MISR_EOI (1 << 0)
 #define 

Re: [Xen-devel] [RFC PATCH 02/10] arm64: Add hook to handle guest GICv3 sysreg accesses

[Manish Jaggi]

On 02/01/2018 04:24 PM, Julien Grall wrote:

Hi Manish,

On 01/02/18 08:51, Manish Jaggi wrote:

On 01/25/2018 11:37 PM, Julien Grall wrote:

Hi,

I forgot to mention one thing about the placement of 
do_fixup_vgic_errata.


On 16/01/18 15:42, mja...@caviumnetworks.com wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f6f6de3691..d4f0581d33 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2103,6 +2103,17 @@ void do_trap_guest_sync(struct cpu_user_regs 
*regs)

  {
  const union hsr hsr = { .bits = regs->hsr };
  +#ifdef CONFIG_VGIC_ERRATA
+    int ret;
+
+    ret  = do_fixup_vgic_errata(regs,hsr);
+    if ( !ret )
+    {
+    advance_pc(regs, hsr);
+    return;


I am fully aware that I suggested this solution and still support 
that the vGIC errata should be fully separated. After all, it deals 
with hardware bug and the errata will just update the LRs as the 
hardware would do.


enter_hypervisor_head() will sync the LRs state to the internal vGIC 
state. leave_hypervisor_head() will process pending softirq and 
write/update the LRs based on the internal vGIC state.


As you rightfully did, the do_fixup_vgic_errata should be called 
before syncing the LRs. However, even if you return early here, you 
will still execute leave_hypervisor_tail(). This mean that pending 
softirqs will be processed and potentially the vCPU rescheduled. 
Because the LRs were not synced (enter_hypervisor_head()) was not 
called, then the vGIC state will not out-of-date and would lead to 
all sort of potential issues.


As the vGIC errata implies trapping the register such as IAR1 
(reading interrupt), we want to get a fastpath for it (e.g not 
trying to execute softirq...). So I think we should bypass 
leave_hypervisor_tail(). I am not entirely sure how to do it nicely 
thought.




How about adding a check for group1_trap enable in 
leave_hypervisor_tail().


void leave_hypervisor_tail(void)
{
+if (group1_trap)
+   return;


I guess you mean the variable you introduced in patch #10. In that 
case, this would be totally wrong. You only want to skip 
leave_hypervisor_tail() when you are handling a ICV_* System registers.


What you want is adding a bool in the structure cpu_info to tell 
whether leave_hypervisor_tail() should be skipped.



Why would it be wrong? I don't follow our point.
Also adding a flag in cpu_info would be overkill, use of a global 
variable is simpler.

I am planning to remove group1_trap as a command line, and use it as

static void gicv3_hyp_init(void)
{
...
#ifdef CONFIG_CAVIUM_ERRATUM_30115
    if (cpus_have_const_cap(ARM64_WORKAROUND_CAVIUM_30115))
    group1_trap = 1;
#endif
...
}


Cheers,




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

Re: [Xen-devel] [RFC PATCH 01/10] Add CONFIG_VGIC_ERRATA

[Manish Jaggi]

Hi Julien,


On 01/25/2018 07:18 PM, Julien Grall wrote:

Hi Manish,

On 16/01/18 15:42, mja...@caviumnetworks.com wrote:

From: Manish Jaggi <manish.ja...@cavium.com>

Add a config option to enable VGIC Errata Code in Xen. Platforms 
which do not

have this errta can compile out this feature.


s/errta/errata/



Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/Kconfig | 9 +
  1 file changed, 9 insertions(+)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index f58019d6ed..2966e3a3d3 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -59,6 +59,15 @@ config SBSA_VUART_CONSOLE
    endmenu
  +menu "Errata Workarounds"
+   depends on ARM_64


I would much prefer to see the memu "ARM errata workaround via..." 
renamed to "Errata Workarounds". So we have only one menu with all 
workarounds.

I am not sure it would work as
menu "ARM errata workaround via the alternative framework"
    depends on HAS_ALTERNATIVE

which may not be correct for vGIC errata.



+
+config VGIC_ERRATA
+   bool "Handler code for emulation of Group0/1 vGIC registers 
for VGC Errata"


The title does not help the user to know when to select this option or 
not.


It looks like to me you want to do something similar to commit 
690a341577f9 "arm64: Add workaround for Cavium Thunder erratum 30115" 
in Linux where the config is called CAVIUM_ERRATA_30115 and a proper 
description explaining the platform affected.



ok

+   depends on ARM_64


I think this should depend on HAS_GICV3.


ok

+
+endmenu
+
  menu "ARM errata workaround via the alternative framework"
  depends on HAS_ALTERNATIVE



Cheers,




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

Re: [Xen-devel] [PATCH 0/7] xen/arm: PSCI 1.1 and SMCCC-1.1 support and XSA-254 variant 2 update

[Manish Jaggi]

Hi Julien,


On 02/05/2018 06:50 PM, Julien Grall wrote:

Hi all,

Arm has recently published a SMC Calling Convention (SMCCC)
specification update [1] that provides an optimised calling convention
and optional, discoverable support for mitigating CVE-2017-5715 (XSA-254
variant 2). ARM Trusted Firmware (ATF) has already gained such an
implementation[2].

This series addresses a few things:

 - It provides a Xen implementation of PSCI v1.0, which is a prerequisite
   for being able to discover SMCCC v1.1.
 - It allows Xen to advertise SMCCC v1.1
 - It implements Xen support for the ARM_WORKAROUND_1 function that is used
   to mitigate CVE-2017-5715 (if such mitigation is available on the
   hypervisor).

This method is intended to fully replace the initial PSCI_GET_VERSION
approach. Although PSCI_GET_VERSION still works, it has an obvious
overhead and is called on some of the hottest paths. We expect
ARCH_WORKAROUND_1 to be much faster.

Another series will be sent to allow the hypervisor discovering SMCCC 1.1 and
use it for the mitigation.

This series is based on the "xen/arm: SMCCC fixes and PSCI clean-up" one [3].

Cheers,

[1]: 
https://developer.arm.com/-/media/developer/pdf/ARM%20DEN%200070A%20Firmware%20interfaces%20for%20mitigating%20CVE-2017-5715_V1.0.pdf

This link is not working.


[2]: https://github.com/ARM-software/arm-trusted-firmware/pull/1240

[3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00117.html

Julien Grall (7):
   xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu
   xen/arm: psci: Rework the PSCI definitions
   xen/arm: vpsci: Add support for PSCI 1.1
   xen/arm: vsmc: Implement SMCCC 1.1
   xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support
   xen/arm: Adapt smccc.h to be able to use it in assembly code
   xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

  tools/libxl/libxl_arm.c  |  3 +-
  xen/arch/arm/arm64/entry.S   | 56 +-
  xen/arch/arm/domain_build.c  |  1 +
  xen/arch/arm/platforms/seattle.c |  4 +-
  xen/arch/arm/psci.c  | 10 ++---
  xen/arch/arm/vpsci.c | 85 +---
  xen/arch/arm/vsmc.c  | 41 +++
  xen/include/asm-arm/perfc_defn.h |  1 +
  xen/include/asm-arm/processor.h  |  2 +
  xen/include/asm-arm/psci.h   | 38 ++
  xen/include/asm-arm/smccc.h  | 37 ++---
  xen/include/asm-arm/vpsci.h  |  2 +-
  12 files changed, 225 insertions(+), 55 deletions(-)




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

Re: [Xen-devel] [PATCH 03/10] arm64: Add ICV_BPR1_EL1 handler

[Manish Jaggi]

On 01/25/2018 10:14 PM, Julien Grall wrote:

Hi Manish,

On 16/01/18 15:42, mja...@caviumnetworks.com wrote:

From: Manish Jaggi <manish.ja...@cavium.com>

Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.


This commit (and likely the followings) is coming from Linux, right? 
If it matches commit from Linux, then you need to keep tags and point 
to the Linux commit. See commit 7762c2d6f4 in Xen as an example to how 
to do it.


If you make changes for Xen, then write "Adapted for Xen...".

ok


But looking at the patch the major difference is you use Xen coding 
style. The rest is pretty much use Xen name for access register and 
adding missing define.


I think it would be beneficial for Xen to re-use Linux code. The 
compatibility layer should be very limited. Stefano any opinions?
So when you mean linux code, you refer to a patch or importing the code 
file from linux ?


Cheers,




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

Re: [Xen-devel] [PATCH 06/10] Expose gicv3_ich_read/write_lr

[Manish Jaggi]

On 01/25/2018 10:22 PM, Julien Grall wrote:

Hi,

On 16/01/18 15:43, mja...@caviumnetworks.com wrote:

From: Manish Jaggi <manish.ja...@cavium.com>

gicv3_ich_read/write_lr functions are static in gic-v3.c
This patch creates wrapper functions which can be used from outside 
the file.


Signed-off-by: Manish Jaggi <manish.ja...@cavium.com>
---
  xen/arch/arm/gic-v3.c    | 10 ++
  xen/include/asm-arm/gic_v3.h |  7 +++
  2 files changed, 17 insertions(+)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 473e26111f..5dba8bc932 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -184,6 +184,11 @@ static uint64_t gicv3_ich_read_lr(int lr)
  }
  }
  +uint64_t __gicv3_ich_read_lr(int lr)


I see no reason to have a wrapper with exactly the same parameters. 
Just export the current one.


But I think I would prefer the function to be redefined in the cpu if 
implementation. So we vGIC errata is fully separated from the rest of 
Xen.

ok, will do.



+{
+    return gicv3_ich_read_lr(lr);
+}
+
  static void gicv3_ich_write_lr(int lr, uint64_t val)
  {
  switch ( lr )
@@ -242,6 +247,11 @@ static void gicv3_ich_write_lr(int lr, uint64_t 
val)

  isb();
  }
  +void __gicv3_ich_write_lr(int lr, uint64_t val)
+{
+    return gicv3_ich_write_lr(lr, val);
+}
+
  /*
   * System Register Enable (SRE). Enable to access CPU & Virtual
   * interface registers as system registers in EL2
diff --git a/xen/include/asm-arm/gic_v3.h b/xen/include/asm-arm/gic_v3.h
new file mode 100644
index 00..544aad5932
--- /dev/null
+++ b/xen/include/asm-arm/gic_v3.h
@@ -0,0 +1,7 @@
+#ifndef GICV3_H
+#define GICV3_H
+
+uint64_t __gicv3_ich_read_lr(int lr);
+void __gicv3_ich_write_lr(int lr, uint64_t val);
+
+#endif



Cheers,




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

Re: [Xen-devel] [PATCH 10/10] Enable Trapping of Group1 registers which is controlled by command line

[Manish Jaggi]

On 01/25/2018 10:30 PM, Julien Grall wrote:

Hi Manish,

On 16/01/18 15:43, mja...@caviumnetworks.com wrote:

From: Manish Jaggi <manish.ja...@cavium.com>

In order to be able to trap Group-1 GICv3 system registers, we need to
set ICH_HCR_EL2.TALL1 before entering the guest. This is controlled by
the command line parameter group1_trap.


I was expecting a patch to enable group1_trap by default on affected 
platform.

ok I will add another patch for that.



[...]

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