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
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
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.
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
---
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
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(+)
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 =
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;
>
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
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
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
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
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
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
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
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
___
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
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
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.
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
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;
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
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.
> +
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
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
44 matches
Mail list logo