Re: [RFC PATCH 24/33] irqchip/gic-v3-its: Add VPE scheduling

Hi Marc, On 01/17/2017 04:20 AM, Marc Zyngier wrote: When a VPE is scheduled to run, the corresponding redistributor must be told so, by setting VPROPBASER to the VM's property table, and VPENDBASER to the vcpu's pending table. When scheduled out, we preserve the IDAI and PendingLast bits. The

Re: [RFC PATCH 28/33] irqchip/gic-v3-its: Support VPE doorbell invalidation even when !DirectLPI

Hi Marc, On 01/17/2017 04:20 AM, Marc Zyngier wrote: When we don't have the DirectLPI feature, we must work around the architecture shortcomings to be able to perform the required invalidation. For this, we create a fake device whose sole purpose is to provide a way to issue a map/inv/unmap

Re: [RFC PATCH 24/33] irqchip/gic-v3-its: Add VPE scheduling

Hi Marc, On 01/17/2017 04:20 AM, Marc Zyngier wrote: When a VPE is scheduled to run, the corresponding redistributor must be told so, by setting VPROPBASER to the VM's property table, and VPENDBASER to the vcpu's pending table. When scheduled out, we preserve the IDAI and PendingLast bits.

Re: [RFC PATCH 23/33] irqchip/gic-v3-its: Add VPENDBASER/VPROPBASER accessors

Hi Marc, On 01/17/2017 04:20 AM, Marc Zyngier wrote: V{PEND,PROP}BASER being 64bit registers, they need some ad-hoc accessors on 32bit, specially given that VPENDBASER contains a Valid bit, making the access a bit convoluted. Signed-off-by: Marc Zyngier ---

Re: [RFC PATCH 21/33] irqchip/gic-v3-its: Add VPE irq domain allocation/teardown

Hi Marc, On 01/17/2017 04:20 AM, Marc Zyngier wrote: When creating a VM, the low level GICv4 code is responsible for: - allocating each VPE a unique VPEID - allocating a doorbell interrupt for each VPE - allocating the pending tables for each VPE - allocating the property table for the VM

Re: [RFC PATCH 17/33] irqchip/gic-v3-its: Add VLPI configuration hook

On 01/17/2017 04:20 AM, Marc Zyngier wrote: Add the skeleton irq_set_vcpu_affinity method that will be used to configure VLPIs. Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 33 + 1 file changed, 33 insertions(+)

Re: [PATCH V8 06/10] acpi: apei: panic OS with fatal error status block

Hello James, On 2/9/2017 3:48 AM, James Morse wrote: Hi Jonathan, Tyler, On 01/02/17 17:16, Tyler Baicar wrote: From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the

Re: [RFC PATCH 11/33] irqchip/gic-v3-its: Split out pending table allocation

Hi Marc, On 01/17/2017 04:20 AM, Marc Zyngier wrote: Just as for the property table, let's move the pending table allocation to a separate function. Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 29 - 1 file changed,

Re: [RFC PATCH 10/33] irqchip/gic-v4-its: Allow use of indirect VCPU tables

Hi Marc, On 01/17/2017 04:20 AM, Marc Zyngier wrote: The VCPU tables can be quite sparse as well, and it makes sense to use indirect tables as well if possible. The VCPU table has maximum of 2^16 entries as compared to 2^32 entries in device table. ITS hardware implementations may not support

Re: [RFC PATCH 06/33] irqchip/gic-v3-its: Add probing for VLPI properties

On 01/17/2017 04:20 AM, Marc Zyngier wrote: Add the probing code for the ITS VLPI support. This includes configuring the ITS number if not supporting the single VMOVP command feature. Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3-its.c | 47

Re: [RFC PATCH 02/33] irqchip/gic-v3: Add VLPI/DirectLPI discovery

On 01/17/2017 04:20 AM, Marc Zyngier wrote: Add helper functions that probe for VLPI and DirectLPI properties. Signed-off-by: Marc Zyngier --- drivers/irqchip/irq-gic-v3.c | 22 ++ include/linux/irqchip/arm-gic-v3.h | 3 +++ 2 files

Re: [RFC PATCH 01/33] irqchip/gic-v3: Add redistributor iterator

Hi Marc, On 01/17/2017 04:20 AM, Marc Zyngier wrote: In order to discover the VLPI properties, we need to iterate over the redistributor regions. As we already have code that does this, let's factor it out and make it slightly more generic. Signed-off-by: Marc Zyngier

Re: [RFC PATCH 00/33] irqchip: Core support for GICv4

Marc, On Tue, 17 Jan 2017, Marc Zyngier wrote: > This series implements the core support for GICv4. And despite its > size, it does exactly *nothing*. What it adds is an infrastructure > that a hypervisor (KVM) can use to route VLPIs to a guest. That's a very well done patch set and it was a

Re: [RFC PATCH 33/33] irqchip/gic-v4: Enable low-level GICv4 operations

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Get the show on the road... > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu

Re: [RFC PATCH 32/33] irqchip/gic-v4: Add some basic documentation

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Do a braindump of the way things are supposed to work. > > Signed-off-by: Marc Zyngier Nice ! Reviewed-by: Thomas Gleixner ___ kvmarm mailing list

Re: [RFC PATCH 31/33] irqchip/gic-v4: Add VLPI configuration interface

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Add the required interfaces to map, unmap and update a VLPI. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner ___ kvmarm mailing list

Re: [RFC PATCH 30/33] irqchip/gic-v4: Add VPE command interface

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Add the required interfaces to schedule a VPE and perform a > VINVALL command. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner ___ kvmarm mailing list

Re: [RFC PATCH 29/33] irqchip/gic-v4: Add per-VM VPE domain creation

On Tue, 17 Jan 2017, Marc Zyngier wrote: > When creating a VM, it is very convenient to have an irq domain > containing all the doorbell interrupts associated with that VM > (each interrupt representing a VPE). > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner

Re: [RFC PATCH 28/33] irqchip/gic-v3-its: Support VPE doorbell invalidation even when !DirectLPI

On Tue, 17 Jan 2017, Marc Zyngier wrote: > When we don't have the DirectLPI feature, we must work around the > architecture shortcomings to be able to perform the required > invalidation. > > For this, we create a fake device whose sole purpose is to > provide a way to issue a map/inv/unmap

Re: [RFC PATCH 27/33] irqchip/gic-v3-its: Add VPE interrupt masking

On Tue, 17 Jan 2017, Marc Zyngier wrote: > When masking/unmasking a doorbell interrupt, it is necessary > to issue an invalidation to the corresponding redistributor. > We use the DirectLPI feature by writting directly to the corresponding > redistributor. > > Signed-off-by: Marc Zyngier

Re: [RFC PATCH 26/33] irqchip/gic-v3-its: Add VPE affinity changes

On Tue, 17 Jan 2017, Marc Zyngier wrote: > When we're about to run a vcpu, it is crucial that the redistributor > associated with the physical CPU is being told about the new residency. > > This is abstracted by hijacking the irq_set_affinity method for the > doorbell interrupt associated with

Re: [RFC PATCH 24/33] irqchip/gic-v3-its: Add VPE scheduling

On Tue, 17 Jan 2017, Marc Zyngier wrote: > +static int its_vpe_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) > +{ > + struct its_vpe *vpe = irq_data_get_irq_chip_data(d); > + struct its_cmd_info *info = vcpu_info; > + u64 val; > + > + switch (info->cmd_type) { > + case

Re: [RFC PATCH 25/33] irqchip/gic-v3-its: Add VPE invalidation hook

On Tue, 17 Jan 2017, Marc Zyngier wrote: > When a guest issues a INVALL command targetting a collection, it must > be translated into a VINVALL for the VPE that has this collection. > > This patch implements a hook that offers this functionallity to the > hypervisor. > > Signed-off-by: Marc

Re: [RFC PATCH 23/33] irqchip/gic-v3-its: Add VPENDBASER/VPROPBASER accessors

On Tue, 17 Jan 2017, Marc Zyngier wrote: > V{PEND,PROP}BASER being 64bit registers, they need some ad-hoc > accessors on 32bit, specially given that VPENDBASER contains > a Valid bit, making the access a bit convoluted. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas

Re: [RFC PATCH 22/33] irqchip/gic-v3-its: Add VPE irq domain [de]activation

On Tue, 17 Jan 2017, Marc Zyngier wrote: > On activation, a VPE is mapped using the VMAPP command, followed > by a VINVALL for a good measure. On deactivation, the VPE is > simply unmapped. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner

Re: [RFC PATCH 21/33] irqchip/gic-v3-its: Add VPE irq domain allocation/teardown

On Tue, 17 Jan 2017, Marc Zyngier wrote: > +static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int > virq, > + unsigned int nr_irqs, void *args) > +{ > + msi_alloc_info_t *info = args; > + struct its_vpe **vpes =

Re: [RFC PATCH 20/33] irqchip/gic-v3-its: Add VPE domain infrastructure

On Tue, 17 Jan 2017, Marc Zyngier wrote: > @@ -2266,6 +2294,8 @@ int __init its_init(struct fwnode_handle *handle, > struct rdists *rdists, > struct irq_domain *parent_domain) > { > struct device_node *of_node; > + struct its_node *its; > + bool has_v4 = false; >

Re: [RFC PATCH 19/33] irqchip/gic-v3-its: Add VLPI configuration handling

On Tue, 17 Jan 2017, Marc Zyngier wrote: > When a VLPI is reconfigured (enabled, disabled, change in priority), > the full configuration byte must be written, and the caches invalidated. > > Also, when using the irq_mask/irq_unmask methods, it is necessary > to disable the doorbell for that

Re: [RFC PATCH 17/33] irqchip/gic-v3-its: Add VLPI configuration hook

On Tue, 17 Jan 2017, Marc Zyngier wrote: > +static int its_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu_info) > +{ > + struct its_device *its_dev = irq_data_get_irq_chip_data(d); > + struct its_cmd_info *info = vcpu_info; > + u32 event = its_get_event_id(d); > + > + /* Need

Re: [RFC PATCH 16/33] irqchip/gic-v3-its: Add GICv4 ITS command definitions

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Add the new GICv4 ITS command definitions, most of them, being > defined in terms of their physical counterparts. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner

Re: [RFC PATCH 15/33] irqchip/gic-v4: Add management structure definitions

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Add a bunch of GICv4-specific data structures that will get used in > subsequent patches. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner ___ kvmarm

Re: [RFC PATCH 14/33] irqchip/gic-v3-its: Generalize LPI configuration

On Tue, 17 Jan 2017, Marc Zyngier wrote: > We're are going to need to change a bit more than just the enable > bit in the LPI property table in the future. So let's change the > LPI configuration funtion to take a set of bits to be cleared, > and a set of bits to be set. > > This way, we'll be

Re: [RFC PATCH 13/33] irqchip/gic-v3-its: Generalize device table allocation

On Tue, 17 Jan 2017, Marc Zyngier wrote: > As we want to use 2-level tables for VCPUs, let's hack the device > table allocator in order to make it slightly more generic. It > will get reused in subsequent patches. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas

Re: [RFC PATCH 12/33] irqchip/gic-v3-its: Rework LPI freeing

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Rework LPI deallocation so that it can be reused by the v4 support > code. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner ___ kvmarm mailing list

Re: [RFC PATCH 11/33] irqchip/gic-v3-its: Split out pending table allocation

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Just as for the property table, let's move the pending table > allocation to a separate function. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner ___

Re: [RFC PATCH 10/33] irqchip/gic-v4-its: Allow use of indirect VCPU tables

On Tue, 17 Jan 2017, Marc Zyngier wrote: > The VCPU tables can be quite sparse as well, and it makes sense > to use indirect tables as well if possible. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner

Re: [RFC PATCH 08/33] irqchip/gic-v3-its: Implement irq_set_irqchip_state for pending state

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Allow the pending state of an LPI to be set or cleared via > irq_set_irqchip_state. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner ___ kvmarm mailing

Re: [RFC PATCH 07/33] irqchip/gic-v3-its: Macro-ize its_send_single_command

On Tue, 17 Jan 2017, Marc Zyngier wrote: > + > +static __its_send_single_cmd(its_send_single_command, its_cmd_builder_t, > + struct its_collection, its_build_sync_cmd) I'm fine with that macro magic, but the above is very unintuitive as it looks like a normal function.

Re: [RFC v2 05/19] KVM: arm64: ITS: Implement vgic_its_has_attr_regs and attr_regs_access

Hi Andre, On 10/02/2017 18:06, Andre Przywara wrote: > Hi, > > On 10/02/17 12:26, Auger Eric wrote: >> Hi Andre, >> >> On 10/02/2017 12:57, Andre Przywara wrote: >>> On 08/02/17 11:43, Eric Auger wrote: >>> >>> Salut Eric, >>> >>> one minor thing below, but first a general question: >>> I take

Re: [RFC PATCH 06/33] irqchip/gic-v3-its: Add probing for VLPI properties

On Tue, 17 Jan 2017, Marc Zyngier wrote: > + typer = gic_read_typer(its_base + GITS_TYPER); > its->base = its_base; > its->phys_base = res->start; > - its->ite_size = ((gic_read_typer(its_base + GITS_TYPER) >> 4) & 0xf) + > 1; > + its->ite_size = ((typer >> 4) & 0xf) + 1;

Re: [RFC PATCH 04/33] irqchip/gic-v3-its: Move LPI definitions around

On Tue, 17 Jan 2017, Marc Zyngier wrote: > The various LPI definitions are in the middle of the code, and > would be better placed at the beginning, given that we're going > to use some of them much earlier. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner

Re: [RFC PATCH 03/33] irqchip/gic-v3-its: Refactor command encoding

On Tue, 17 Jan 2017, Marc Zyngier wrote: > +static void its_mask_encode(u64 *raw_cmd, u64 val, int h, int l) I'd rather name h/l in a way which makes it clear that they are describing a bit range. msb/lsb perhaps. > +{ > + u64 mask = GENMASK_ULL(h, l); New line missing here. > +

Re: [RFC PATCH 02/33] irqchip/gic-v3: Add VLPI/DirectLPI discovery

On Tue, 17 Jan 2017, Marc Zyngier wrote: > Add helper functions that probe for VLPI and DirectLPI properties. > > Signed-off-by: Marc Zyngier Reviewed-by: Thomas Gleixner ___ kvmarm mailing list

Re: [RFC PATCH 01/33] irqchip/gic-v3: Add redistributor iterator

On Tue, 17 Jan 2017, Marc Zyngier wrote: > In order to discover the VLPI properties, we need to iterate over > the redistributor regions. As we already have code that does this, > let's factor it out and make it slightly more generic. > > Signed-off-by: Marc Zyngier