Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, >> So Xen does not need to throw in its own ideas here. Which would avoid >> some of the hard problems we encountered. > I got all your point. > Just question. Why does existing CPUFreq on x86 have own logic? Do we have > something yet another on ARM that having own logic in Xen doesn't

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, On 16/11/17 14:57, Oleksandr Tyshchenko wrote: > On Wed, Nov 15, 2017 at 4:28 PM, Andre Przywara > <andre.przyw...@linaro.org> wrote: >> Hi, > Hi Andre, Jassi > > Thank you for your comments! > >> >> On 14/11/17 20:46, Oleksandr Tyshchenko wrote: &

[Xen-devel] [PATCH] arm64: ITS: fix cacheability adjustment

this by removing the one redundant masking operation and adding the magic negation for the actually needed other operation. Reported-by: Manish Jaggi <manish.ja...@linaro.org> Signed-off-by: Andre Przywara <andre.przyw...@linaro.org> --- Julien, can we have this still for 4.10, please? Seems like an

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, On 14/11/17 20:46, Oleksandr Tyshchenko wrote: > On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara > <andre.przyw...@linaro.org> wrote: >> Hi, > Hi Andre > >> >> On 13/11/17 19:40, Oleksandr Tyshchenko wrote: >>> On Mon, Nov 13, 2017 at 5:21 PM,

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, On 15/11/17 03:03, Jassi Brar wrote: > On 15 November 2017 at 02:16, Oleksandr Tyshchenko <olekst...@gmail.com> > wrote: >> On Tue, Nov 14, 2017 at 12:49 PM, Andre Przywara >> <andre.przyw...@linaro.org> wrote: >> > >>>>>> 3. Direct

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, On 13/11/17 19:40, Oleksandr Tyshchenko wrote: > On Mon, Nov 13, 2017 at 5:21 PM, Andre Przywara > <andre.przyw...@linaro.org> wrote: >> Hi, > Hi Andre > >> >> thanks very much for your work on this! > Thank you for your comments. > >>

Re: [Xen-devel] [RFC PATCH 00/31] CPUFreq on ARM

Hi, thanks very much for your work on this! On 09/11/17 17:09, Oleksandr Tyshchenko wrote: > From: Oleksandr Tyshchenko > > Hi, all. > > The purpose of this RFC patch series is to add CPUFreq support to Xen on ARM. > Motivation of hypervisor based CPUFreq is to

Re: [Xen-devel] [PATCH 04/12] ARM: VGIC: move gic_remove_irq_from_queues()

Hi, ... >> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h >> index e489d0bf21..8d0ff65708 100644 >> --- a/xen/include/asm-arm/vgic.h >> +++ b/xen/include/asm-arm/vgic.h >> @@ -204,6 +204,7 @@ extern int vcpu_vgic_init(struct vcpu *v); >> extern struct vcpu

Re: [Xen-devel] [PATCH 03/12] ARM: VGIC: remove gic_clear_pending_irqs()

Hi, On 26/10/17 01:14, Stefano Stabellini wrote: > On Thu, 19 Oct 2017, Andre Przywara wrote: >> gic_clear_pending_irqs() was not only misnamed, but also misplaced, as >> a function solely dealing with the GIC emulation should not live in gic.c. >> Move the functionality of t

Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document

Hi, On 01/11/17 21:54, Stefano Stabellini wrote: > On Wed, 1 Nov 2017, Andre Przywara wrote: >> Hi Stefano, >> >> >> On 01/11/17 01:58, Stefano Stabellini wrote: >>> On Wed, 11 Oct 2017, Andre Przywara wrote: >> >> many thanks for going through al

Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document

Hi Christoffer, On 12/10/17 13:05, Christoffer Dall wrote: > Hi Andre, > > On Wed, Oct 11, 2017 at 03:33:03PM +0100, Andre Przywara wrote: >> Hi, >> >> (CC:ing some KVM/ARM folks involved in the VGIC) > > Very nice writeup! > > I added a bunch of comments

Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document

Hi Stefano, On 01/11/17 01:58, Stefano Stabellini wrote: > On Wed, 11 Oct 2017, Andre Przywara wrote: many thanks for going through all of this! >> (CC:ing some KVM/ARM folks involved in the VGIC) >> >> starting with the addition of the ITS support we were seeing mo

Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document

Hi, On 01/11/17 04:31, Christoffer Dall wrote: > On Wed, Nov 1, 2017 at 9:58 AM, Stefano Stabellini > wrote: > > [] Christoffer, many thanks for answering this! I think we have a lot of assumptions about the whole VGIC life cycle floating around, but it would indeed

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

Hi, On 25/10/17 09:22, Manish Jaggi wrote: > > > On 10/23/2017 7:27 PM, Andre Przywara wrote: >> Hi Manish, >> >> On 12/10/17 22:03, Manish Jaggi wrote: >>> ACPI/IORT Support in Xen. >>> -- >>> >>&

[Xen-devel] [PATCH v3 1/2] arm/xen: vpl011: Fix the slow early console SBSA UART output

ole so it is safe to set the BUSY bit only when FIFO becomes full. This will ensure that pl011_early_write() is not delayed unduly to write the data. Signed-off-by: Bhupinder Thakur <bhupinder.tha...@linaro.org> Reviewed-by: Andre Przywara <andre.przyw...@linaro.org> Signed-off-by: Andre Prz

[Xen-devel] [PATCH v3 2/2] arm/xen: vpl011: Fix SBSA UART interrupt assertion

comments] Signed-off-by: Bhupinder Thakur <bhupinder.tha...@linaro.org> Reviewed-by: Andre Przywara <andre.przyw...@linaro.org> Signed-off-by: Andre Przywara <andre.przyw...@linaro.org> --- xen/arch/arm/vpl011.c| 131 ++- xen/

Re: [Xen-devel] [PATCH RFC] ARM: vPL011: use receive timeout interrupt

Hi, On 24/10/17 12:00, Julien Grall wrote: > Hi, > > On 23/10/2017 17:01, Andre Przywara wrote: >> Hi, >> >> On 18/10/17 17:32, Bhupinder Thakur wrote: >>> Hi Andre, >>> >>> I verified this patch on qualcomm platform. It is working fin

Re: [Xen-devel] [PATCH RFC] ARM: vPL011: use receive timeout interrupt

Hi, On 18/10/17 17:32, Bhupinder Thakur wrote: > Hi Andre, > > I verified this patch on qualcomm platform. It is working fine. > > On 18 October 2017 at 19:11, Andre Przywara <andre.przyw...@arm.com> wrote: >> Instead of asserting the receive interrupt (

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

Hi Manish, On 12/10/17 22:03, Manish Jaggi wrote: > ACPI/IORT Support in Xen. > -- > > I had sent out patch series [0] to hide smmu from Dom0 IORT. Extending > the scope > and including all that is required to support ACPI/IORT in Xen. > Presenting for review

Re: [Xen-devel] [PATCH v2] arm: configure interrupts to be in non-secure group1

why we didn't see the issue before. Now with QEMU there might be no secure firmware, also the emulated GIC only provides a single security state, so we have to set this up ourselves. > Signed-off-by: Stefano Stabellini <sstabell...@kernel.org> Reviewed-by: Andre Przywara <andre.p

Re: [Xen-devel] [PATCH 00/12] ARM: VGIC/GIC separation cleanups

Hi, On 19/10/17 13:48, Andre Przywara wrote: > By the original VGIC design, Xen differentiates between the actual VGIC > emulation on one hand and the GIC hardware accesses on the other. > It seems there were some deviations from that scheme (over time?), so at > the moment we en

[Xen-devel] [PATCH 07/12] ARM: VGIC: split gic.c to observe hardware/virtual GIC separation

into a separate file, so that gic.c does what is says on the tin. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/Makefile | 1 + xen/arch/arm/gic-vgic.c | 395 xen/arch/arm/gic.c

[Xen-devel] [PATCH 10/12] ARM: VGIC: factor out vgic_connect_hw_irq()

said accesses to VGIC data structures and improves abstraction. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/gic-vgic.c| 31 +++ xen/arch/arm/gic.c | 42 ++ xen/include/asm-arm/vgic.h | 2

[Xen-devel] [PATCH 04/12] ARM: VGIC: move gic_remove_irq_from_queues()

gic_remove_irq_from_queues() was not only misnamed, it also has the wrong abstraction, as it should not live in gic.c. Move it into vgic.c and vgic.h, where it belongs to, and rename it on the way. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/gic.c

[Xen-devel] [PATCH 01/12] ARM: remove unneeded gic.h inclusions

they are actually not needed. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/domain_build.c | 1 - xen/arch/arm/p2m.c | 1 - xen/arch/arm/platforms/vexpress.c| 1 - xen/arch/arm/platforms/xgene-storm.c | 1 - xen/arch/arm/time.c

[Xen-devel] [PATCH 02/12] ARM: vGIC: fix nr_irq definition

as a local variable name or as a function parameter. Drop the optimization and make nr_irqs a normal variable for ARM also. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/irq.c| 2 ++ xen/include/asm-arm/irq.h | 2 +- 2 files changed, 3 insertions(+), 1 del

[Xen-devel] [PATCH 08/12] ARM: VGIC: split up gic_dump_info() to cover virtual part separately

Currently gic_dump_info() not only dumps the hardware state of the GIC, but also the VGIC internal virtual IRQ lists. Split the latter off and move it into vgic.c to observe the abstraction. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/domain.c | 1 + xe

[Xen-devel] [PATCH 05/12] ARM: VGIC: move gic_remove_from_lr_pending()

gic_remove_from_lr_pending() was not only misnamed, it also had the wrong abstraction, as it should not live in gic.c. Move it into vgic.c and vgic.h, where it belongs, and rename it on the way. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/gic.c

[Xen-devel] [PATCH 11/12] ARM: VGIC: factor out vgic_get_hw_irq_desc()

At the moment we happily access the VGIC internal struct pending_irq (which describes a virtual IRQ) in irq.c. Factor out the actually needed functionality to learn the associated hardware IRQ and move that into gic-vgic.c to improve abstraction. Signed-off-by: Andre Przywara <andre.pr

[Xen-devel] [PATCH 06/12] ARM: VGIC: streamline gic_restore_pending_irqs()

-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/domain.c | 1 + xen/arch/arm/gic.c| 11 +-- xen/arch/arm/traps.c | 2 +- xen/include/asm-arm/gic.h | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/ar

[Xen-devel] [PATCH 12/12] ARM: VGIC: rework gicv[23]_update_lr to not use pending_irq

The functions to actually populate a list register were accessing the VGIC internal pending_irq struct, although they should be abstracting from that. Break the needed information down to remove the reference to pending_irq from gic-v[23].c. Signed-off-by: Andre Przywara <andre.przyw...@arm.

[Xen-devel] [PATCH 00/12] ARM: VGIC/GIC separation cleanups

ideas on improvements are welcome. Cheers, Andre. Andre Przywara (12): ARM: remove unneeded gic.h inclusions ARM: vGIC: fix nr_irq definition ARM: VGIC: remove gic_clear_pending_irqs() ARM: VGIC: move gic_remove_irq_from_queues() ARM: VGIC: move gic_remove_from_lr_pending() ARM: VGIC

[Xen-devel] [PATCH 09/12] ARM: VGIC: rework events_need_delivery()

In event.h we very deeply dive into the VGIC to learn if an event for a guest is pending. Rework that function to abstract the VGIC specific part out. Also reorder the queries there, as we only actually need to check for the event channel if there are no other pending IRQs. Signed-off-by: Andre

[Xen-devel] [PATCH 03/12] ARM: VGIC: remove gic_clear_pending_irqs()

gic_clear_pending_irqs() was not only misnamed, but also misplaced, as a function solely dealing with the GIC emulation should not live in gic.c. Move the functionality of this function into its only caller in vgic.c Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm

[Xen-devel] [PATCH RFC] ARM: vPL011: use receive timeout interrupt

Instead of asserting the receive interrupt (RXI) on the first character in the FIFO, lets (ab)use the receive timeout interrupt (RTI) for that purpose. That seems to be closer to the spec and what hardware does. Improve the readability of vpl011_data_avail() on the way. Signed-off-by: Andre

Re: [Xen-devel] [PATCH 26/27 v12] arm/xen: vpl011: Fix the slow early console SBSA UART output

Hi, On 18/10/17 11:17, Bhupinder Thakur wrote: > Hi Andre, > > On 17 October 2017 at 15:21, Andre Przywara <andre.przyw...@arm.com> wrote: >> Hi Bhupinder, >> >> first thing: As the bulk of the series has been merged now, please >> restart your patch and v

Re: [Xen-devel] [PATCH 27/27 v12] arm/xen: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

to clean up my approach and post it. Cheers, Andre. > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183f/DDI0183.pdf > > Signed-off-by: Bhupinder Thakur <bhupinder.tha...@linaro.org> > --- > CC: Julien Grall <julien.gr...@arm.com> > CC: Andre Przywara

Re: [Xen-devel] [PATCH 26/27 v12] arm/xen: vpl011: Fix the slow early console SBSA UART output

problem. Cheers, Andre > Signed-off-by: Bhupinder Thakur <bhupinder.tha...@linaro.org> > --- > CC: Julien Grall <julien.gr...@arm.com> > CC: Andre Przywara <andre.przyw...@arm.com> > CC: Stefano Stabellini <sstabell...@kernel.org> > > xen/arch/arm/vpl01

Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document

Hi, On 11/10/17 15:33, Andre Przywara wrote: > Hi, > > (CC:ing some KVM/ARM folks involved in the VGIC) > > starting with the addition of the ITS support we were seeing more and > more issues with the current implementation of our ARM Generic Interrupt > Controller (GIC

Re: [Xen-devel] [PATCH for-4.10] xen/arm: mm: Rework MAIR* definitions to handle 32-bit compilation environment

eems not too bad for me. > Lastly, a comment is added to avoid trying to blindly combine the both > definition again in the future. > > Signed-off-by: Julien Grall <julien.gr...@linaro.org> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- &g

[Xen-devel] [RFC] ARM: New (Xen) VGIC design document

Hi, (CC:ing some KVM/ARM folks involved in the VGIC) starting with the addition of the ITS support we were seeing more and more issues with the current implementation of our ARM Generic Interrupt Controller (GIC) emulation, the VGIC. Among other approaches to fix those issues it was proposed to

Re: [Xen-devel] [PATCH v5 4/5] ARM: Update Formula to compute MADT size using new callbacks in gic_hw_operations

formula to compute extra MADT size, as per GICv2/3 > by calling gic_get_hwdom_extra_madt_size > > Signed-off-by: Manish Jaggi <mja...@cavium.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Thanks! Andre > --- > xen/arch/arm/domain_build.c | 7 +-- > x

Re: [Xen-devel] [PATCH 27/27 v11] xen/arm: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

> > [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183f/DDI0183.pdf > > Signed-off-by: Bhupinder Thakur <bhupinder.tha...@linaro.org> Only some minor things left below, but in general this looks much better to me now. > --- > CC: Julien Grall <julien.gr..

[Xen-devel] [PATCH] ARM: sunxi: support more Allwinner SoCs

-off-by: Andre Przywara <andre.przyw...@arm.com> --- Hi, this is based on staging, which has the required UART fix. Tested on: - BananaPi M1 (A20) - OrangePi Zero (H2+, which is almost the same as H3) - OrangePi PC 2 (H5, arm64) - Pine64+ (A64, arm64) On the 64-bit boards I could boot int

Re: [Xen-devel] [PATCH v4 5/5] ARM: ITS: Expose ITS in the MADT table

cavium.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/arch/arm/gic-v3-its.c| 19 +++ > xen/arch/arm/gic-v3.c| 1 + > xen/include/asm-arm/gic_v3_its.h | 8 > 3 files changed, 28 insertions(+) >

Re: [Xen-devel] [PATCH v4 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

Hi, On 21/09/17 14:17, mja...@caviumnetworks.com wrote: > From: Manish Jaggi > > estimate_acpi_efi_size needs to be updated to provide correct size of > hardware domains MADT, which now adds ITS information as well. > > Introducing gic_get_hwdom_madt_size. > >

Re: [Xen-devel] [PATCH v4 3/5] ARM: ITS: Deny hardware domain access to ITS

ff-by: Manish Jaggi <mja...@cavium.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Thanks, Andre. > --- > xen/arch/arm/gic-v3-its.c| 22 ++ > xen/arch/arm/gic-v3.c| 3 +++ > xen/include/asm-arm/gic_v3_its.h | 9 + >

Re: [Xen-devel] [PATCH v4 2/5] ARM: ITS: Populate host_its_list from ACPI MADT Table

itecture defined constant. But as it was there before and it seems cleaner to use the DT provided size, it could stay as well. We might fix that later on. >> >>> + >>> +    return 0; >>> +} >>> + >>> +void gicv3_its_acpi_init(void) >>> +{ &g

Re: [Xen-devel] [PATCH v2 1/2] xen/arm64: Add Support for Allwinner H5 (sun50i)

Hi, >>> Since reset routine will not be required with PSCI, I assume should revert >>> the reset code changes for this H5 patch and leave the DT retrieval for >>> another patch that adds H3 support. Or should I try that stuff for next >>> version of this patch? >> >> Thanks for the

Re: [Xen-devel] [PATCH v2 1/2] xen/arm64: Add Support for Allwinner H5 (sun50i)

Hi Awais, On 04/10/17 10:16, Awais Masood wrote: > Hi, > > On 09/29/2017 09:35 PM, Andre Przywara wrote: >> Hi, >> >> On 09/28/2017 03:49 PM, Andre Przywara wrote: >>> Hi, >>> >>> On 09/28/2017 01:03 PM, Julien Grall wrote: >>

Re: [Xen-devel] [PATCH v2 1/2] xen/arm64: Add Support for Allwinner H5 (sun50i)

Hi, On 09/28/2017 03:49 PM, Andre Przywara wrote: Hi, On 09/28/2017 01:03 PM, Julien Grall wrote: Hi, On 09/26/2017 10:37 AM, Awais Masood wrote: This patch adds support for Allwinner H5/sun50i SoC. Makefile updated to enable ARM64 compilation for sunxi.c. ... --- a/xen/arch/arm

Re: [Xen-devel] [PATCH v2 1/2] xen/arm64: Add Support for Allwinner H5 (sun50i)

Hi, On 09/28/2017 01:03 PM, Julien Grall wrote: Hi, On 09/26/2017 10:37 AM, Awais Masood wrote: This patch adds support for Allwinner H5/sun50i SoC. Makefile updated to enable ARM64 compilation for sunxi.c. sunxi.c updates include:    - Addition of H5/sun50i dt compatibility string.    -

Re: [Xen-devel] [PATCH v2 0/2] ARM: ACPI: IORT: Hide SMMU from hardware domain's IORT table

Hi Manish, On 11/09/17 22:33, mja...@caviumnetworks.com wrote: > From: Manish Jaggi > > The set is divided into two patches. First one calculates the size of IORT > while second one writes the IORT table itself. It would be good if you could give a quick introduction *why*

Re: [Xen-devel] [PATCH v2 16/24] xen/arm: page: Use ARMv8 naming to improve readability

Hi, On 21/09/17 16:46, Stefano Stabellini wrote: > On Thu, 21 Sep 2017, Julien Grall wrote: >> Hi, >> >> On 20/09/17 00:45, Stefano Stabellini wrote: diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h index 30fcfa0778..899fd1801a 100644 ---

Re: [Xen-devel] [PATCH v3 5/5] ARM: ITS: Expose ITS in the MADT table

Hi, On 05/09/17 18:15, mja...@caviumnetworks.com wrote: > From: Manish Jaggi > > Add gicv3_its_make_hwdom_madt to update hwdom MADT ITS information. > > Signed-off-by: Manish Jaggi > --- > xen/arch/arm/gic-v3-its.c| 23 +++ >

Re: [Xen-devel] [PATCH v3 3/5] ARM: ITS: Deny hardware domain access to ITS

Hi, On 05/09/17 18:14, mja...@caviumnetworks.com wrote: > From: Manish Jaggi > > This patch extends the gicv3_iomem_deny_access functionality by adding > support for ITS region as well. Add function gicv3_its_deny_access. > > Signed-off-by: Manish Jaggi >

Re: [Xen-devel] [PATCH v3 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

Hi, On 05/09/17 18:14, mja...@caviumnetworks.com wrote: > From: Manish Jaggi > > estimate_acpi_efi_size needs to be updated to provide correct size of > hardware domains MADT, which now adds ITS information as well. > > Introducing gic_get_hwdom_madt_size. > >

Re: [Xen-devel] [PATCH v3 2/5] ARM: ITS: Populate host_its_list from ACPI MADT Table

Hi, On 05/09/17 18:14, mja...@caviumnetworks.com wrote: > From: Manish Jaggi > > Added gicv3_its_acpi_init to update host_its_list from MADT table. > For ACPI, host_its structure stores dt_node as NULL. > > Signed-off-by: Manish Jaggi > --- >

Re: [Xen-devel] [PATCH v3 1/5] ARM: ITS: Introduce common function add_to_host_its_list

Jaggi <mja...@cavium.com> Makes sense. Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/arch/arm/gic-v3-its.c | 32 > 1 file changed, 20 insertions(+), 12 deletions(-) > > diff --git a/xen/arch/arm/gic-v

Re: [Xen-devel] [PATCH 26/27 v8] xen/arm: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

e FIFO. > > [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183f/DDI0183.pdf > > Signed-off-by: Bhupinder Thakur <bhupinder.tha...@linaro.org> > --- > CC: Julien Grall <julien.gr...@arm.com> > CC: Andre Przywara <andre.przyw...@arm.com> > CC: Stefano Sta

Re: [Xen-devel] [PATCH 04/27 v8] xen/arm: vpl011: Add support for vuart in libxl

Hi, On 28/08/17 09:55, Bhupinder Thakur wrote: > An option is provided in libxl to enable/disable SBSA vuart while > creating a guest domain. > > Libxl now supports a generic vuart console and SBSA uart is a specific type. > In future support can be added for multiple vuart of different types. >

Re: [Xen-devel] [PATCH 00/27] xen/arm: Memory subsystem clean-up

Hi Julien, On 14/08/17 15:23, Julien Grall wrote: > Hi all, > > This patch series contains clean-up for the ARM Memory subsystem in > preparation of reworking the page tables handling. thanks for the work! I am done with the review, the series looks fine in general to me. Whenever there were

Re: [Xen-devel] [PATCH 25/27] xen/arm: mm: Embed permission in the flags

Hi, On 23/08/17 15:26, Julien Grall wrote: > On 08/23/2017 03:08 PM, Andre Przywara wrote: >> Hi, > > Hi, > >> On 14/08/17 15:24, Julien Grall wrote: >>> Currently, it is not possible to specify the permission of a new >>> mapping. It would be necessa

Re: [Xen-devel] [PATCH 27/27] xen/arm: mm: Use memory flags for modify_xen_mappings rather than custom one

oved ASSERT is now already cared for in create_xen_entries() (which is also another hint to make that an ASSERT, actually). Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > > --- > > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> >

Re: [Xen-devel] [PATCH 26/27] xen/arm: mm: Handling permission flags when adding a new mapping

Hi, On 14/08/17 15:24, Julien Grall wrote: > Currently, all the new mappings will be read-write non-executable. Allow the > caller to use other permissions. > > Signed-off-by: Julien Grall > --- > xen/arch/arm/mm.c | 8 > 1 file changed, 8 insertions(+) > > diff

Re: [Xen-devel] [PATCH 21/27] xen/arm: mm: Rename and clarify AP[1] in the stage-1 page table

in ARM DDI 0487B.a). Indeed. > > Update the comment and also rename the field to match the description in > the ARM ARM. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/arch/a

Re: [Xen-devel] [PATCH 25/27] xen/arm: mm: Embed permission in the flags

trigger regressions (especially for PAGE_HYPERVISOR). So I wonder if that should be mentioned in the commit message then? The actual patch looks OK though, so: Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > > A follow-up patch will change modify_xen_map

Re: [Xen-devel] [PATCH 24/27] xen/arm: page: Describe the layout of flags used to update page tables

d the patch itself is fine, so: Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/arch/arm/mm.c | 2 +- > xen/include/asm-arm/page.h | 7 +++ > 2 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/arm/mm.c b/x

Re: [Xen-devel] [PATCH 23/27] xen/arm: mm: Rename 'ai' into 'flags' in create_xen_entries

arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/arch/arm/mm.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index c0d5fda269..411fe02842 100644 > -

Re: [Xen-devel] [PATCH 19/27] xen/arm: page: Clean-up the definition of MAIRVAL

tribute shifted by their > associated index. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> I checked all the bits and encoding against the ARMv8 ARM, they look correct to me. However I feel that the attribute renaming patch (20/27) should come before this one. However: Reviewed-b

Re: [Xen-devel] [PATCH 18/27] xen/arm: page: Prefix memory types with MT_

write-allocate > + *aiencoding > + * MT_UNCACHED 000 -- Strongly Ordered > + * MT_BUFFERABLE001 0100 0100 -- Non-Cacheable > + * MT_WRITETHROUGH 010 1010 1010 -- Write-through > + * MT_WRITEBACK 011 1110 1110 -- Write-b

Re: [Xen-devel] [PATCH 20/27] xen/arm: page: Use ARMv8 naming to improve readability

s sense and improves readability as the naming matches the spec and is more intuitive. Also it looks correct to me. However I feel it would be more helpful is this patches comes before the previous one which reworks the MAIR construction. However for this patch: > Signed-off-by: Julien Grall <jul

Re: [Xen-devel] [PATCH 16/27] xen/arm: page: Remove unused attributes DEV_NONSHARED and DEV_CACHED

g our attribute matches Linux. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/include/asm-arm/page.h | 10 +++--- > 1 file changed, 3 insertions(+), 7 deletions(-) > &g

Re: [Xen-devel] [PATCH 22/27] xen/arm: Switch to SYS_STATE_boot just after end_boot_allocator()

y: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/arch/arm/setup.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index 2

Re: [Xen-devel] [PATCH 17/27] xen/arm: page: Use directly BUFFERABLE and drop DEV_WC

Hi, On 14/08/17 15:24, Julien Grall wrote: > DEV_WC is only used for PAGE_HYPERVISOR_WC and does not bring much > improvement. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- >

Re: [Xen-devel] [PATCH 15/27] xen/arm: Replace ioremap_attr(PAGE_HYPERVISOR_NOCACHE) call by ioremap_nocache

Hi, On 14/08/17 15:24, Julien Grall wrote: > ioremap_cache is a wrapper of ioremap_attr(...). > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre > --- > xen/arch/arm/platforms/exynos5.c | 2 +

Re: [Xen-devel] [PATCH 14/27] xen/arm: traps: Improve logging for data/prefetch abort fault

r(is_data)); > +else > +printk("Invalid FAR, don't walk the hypervisor tables\n"); Nit: "not walking" sounds less ambiguous. > +do_unexpected_trap(fault, regs); > > +break; > +} > default: > printk

Re: [Xen-devel] [PATCH 13/27] xen/arm: traps: Introduce a helper to read the hypersivor fault register

ad it too. So move the logic in a separate helper and use it instead > of open-coding it. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/arch/arm/traps.c | 35 +++

Re: [Xen-devel] [PATCH 12/27] xen/arm: Introduce hsr_xabt to gather common bits between hsr_dabt and

Hi, On 14/08/17 15:24, Julien Grall wrote: > This will allow to consolidate some part of the data abort and prefetch > abort handling in a single function later on. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@ar

Re: [Xen-devel] [PATCH 11/27] xen/arm: Add FnV field in hsr_*abt

update the other fields on the way as well, for instance there is now "ar" in Aarch32 also. > Signed-off-by: Julien Grall <julien.gr...@arm.com> But the actual bits are correct, so if we just need "fnv", then this is: Reviewed-by: Andre Przywara <andre.przyw...@

Re: [Xen-devel] [PATCH 10/27] xen/arm: arm32: Don't define FAR_EL1

e copy-and-paste piggy bank ;-) Otherwise it's fine. > As FAR_EL1 is not currently used in ARM32 code, remove it. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/include/asm-arm/cp

Re: [Xen-devel] [PATCH 08/27] xen/arm: hsr_iabt: Document RES0 field

Hi, On 14/08/17 15:23, Julien Grall wrote: > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> > --- > xen/include/asm-arm/processor.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > di

Re: [Xen-devel] [PATCH 09/27] xen/arm: traps: Don't define FAR_EL2 for ARM32

0 in ARM DDI 0487B.a. Open-code the alias instead. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > xen/arch/arm/traps.c | 8 +++- > xen/include/asm-arm/cpregs.h | 1 - > 2 f

Re: [Xen-devel] [PATCH 03/27] xen/x86: mm: Don't check alloc_boot_pages return

lloc_boot_pages(), so the patch is valid. > Signed-off-by: Julien Grall <julien.gr...@arm.com> Given that you adjust the commit message: Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > Cc: Jan Beulich <jbeul...@suse.com> > Cc: Andrew Cooper &

Re: [Xen-devel] [PATCH 02/27] xen/x86: srat: Don't check alloc_boot_pages return

Hi, On 14/08/17 15:23, Julien Grall wrote: > alloc_boot_pages will panic if it is not possible to allocate. So the > check in the caller is pointless. > > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Thanks, An

Re: [Xen-devel] [PATCH 01/27] xen/x86: numa: Don't check alloc_boot_pages return

y, so it doesn't signal an error condition in the first place. > Signed-off-by: Julien Grall <julien.gr...@arm.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Cheers, Andre. > --- > > Cc: Jan Beulich <jbeul...@suse.com> > Cc: Andrew Cooper <andrew.

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

Hi, On 18/08/17 15:21, Julien Grall wrote: > > > On 17/08/17 18:06, Andre Przywara wrote: >> Hi, > > Hi Andre, > >> On 11/08/17 15:10, Julien Grall wrote: >>> Hi Andre, >>> >>> On 21/07/17 20:59, Andre Przywara wrote: >&

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

Hi, On 11/08/17 15:10, Julien Grall wrote: > Hi Andre, > > On 21/07/17 20:59, Andre Przywara wrote: >> Since the GICs MMIO access always covers a number of IRQs at once, >> introduce wrapper functions which loop over those IRQs, take their >> locks and read or

Re: [Xen-devel] [RFC PATCH v2 07/22] ARM: vGIC: introduce priority setter/getter

Hi, On 11/08/17 15:10, Julien Grall wrote: > Hi Andre, > > On 21/07/17 20:59, Andre Przywara wrote: >> Since the GICs MMIO access always covers a number of IRQs at once, >> introduce wrapper functions which loop over those IRQs, take their >> locks and read or

Re: [Xen-devel] [RFC PATCH v2 01/22] ARM: vGIC: introduce and initialize pending_irq lock

Hi, On 10/08/17 16:35, Julien Grall wrote: > Hi, > > On 21/07/17 20:59, Andre Przywara wrote: >> Currently we protect the pending_irq structure with the corresponding >> VGIC VCPU lock. There are problems in certain corner cases (for >> instance if an IRQ is migrating

[Xen-devel] [RFC PATCH v2 17/22] ARM: vGIC: introduce vgic_lock_vcpu_irq()

lock again. Before returning there is a check whether something has changed in the brief period where we didn't hold the IRQ lock, retrying in this (very rare) case. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/vgic.c | 42 +++

[Xen-devel] [RFC PATCH v2 18/22] ARM: vGIC: move virtual IRQ target VCPU from rank to pending_irq

this over to the new lock. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/vgic-v2.c | 56 +++ xen/arch/arm/vgic-v3-its.c | 9 +++--- xen/arch/arm/vgic-v3.c | 69 --- xen/arch/arm/

[Xen-devel] [RFC PATCH v2 21/22] ARM: vITS: injecting LPIs: use pending_irq lock

Instead of using an atomic access and hoping for the best, let's use the new pending_irq lock now to make sure we read a sane version of the target VCPU. That still doesn't solve the problem mentioned in the comment, but paves the way for future improvements. Signed-off-by: Andre Przywara

[Xen-devel] [RFC PATCH v2 09/22] ARM: vITS: protect LPI priority update with pending_irq lock

As the priority value is now officially a member of struct pending_irq, we need to take its lock when manipulating it via ITS commands. Make sure we take the IRQ lock after the VCPU lock when we need both. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/vgic-v3-its.

[Xen-devel] [RFC PATCH v2 14/22] ARM: vGIC: move virtual IRQ configuration from rank to pending_irq

s to store and retrieve the configuration bit for multiple IRQs. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/vgic-v2.c | 21 +++- xen/arch/arm/vgic-v3.c | 25 -- xen/arch/arm/vgic.c| 81 +- xen

[Xen-devel] [RFC PATCH v2 03/22] ARM: vGIC: move gic_raise_inflight_irq() into vgic_vcpu_inject_irq()

this patch is more a temporary kludge. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/gic.c| 30 +- xen/arch/arm/vgic.c | 11 ++- xen/include/asm-arm/gic.h | 2 +- 3 files changed, 12 insertions(+), 31 deletions(-) diff

[Xen-devel] [RFC PATCH v2 04/22] ARM: vGIC: rename pending_irq->priority to cur_priority

rity must stay fixed at this value, subsequenct MMIO accesses to change the priority can only affect newly triggered interrupts. Also since the priority is a sorting criteria for the inflight list, it must not change when it's on a VCPUs list. Signed-off-by: Andre Przywara <andre.przyw...@arm.com>

[Xen-devel] [RFC PATCH v2 12/22] ARM: vGIC: protect gic_update_one_lr() with pending_irq lock

When we return from a domain with the active bit set in an LR, we update our pending_irq accordingly. This touches multiple status bits, so requires the pending_irq lock. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/gic.c | 2 ++ 1 file changed, 2 insertions(+)

[Xen-devel] [RFC PATCH v2 11/22] ARM: vGIC: protect gic_events_need_delivery() with pending_irq lock

gic_events_need_delivery() reads the cur_priority field twice, also relies on the consistency of status bits. So it should take pending_irq lock. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/gic.c | 24 +--- 1 file changed, 13 insertions(

[Xen-devel] [RFC PATCH v2 20/22] ARM: vGIC: move virtual IRQ enable bit from rank to pending_irq

r enabling/disabling of multiple IRQs. This also marks the removal of the last member of struct vgic_irq_rank. Signed-off-by: Andre Przywara <andre.przyw...@arm.com> --- xen/arch/arm/vgic-v2.c | 41 +++-- xen/arch/arm/vgic-v3.c | 41 +++-- xen/arch/arm/vgi

  1   2   3   4   5   6   7   8   >