From: Marc Zyngier <maz@kernel.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jason Cooper <jason@lakedaemon.net>,
Robert Richter <rrichter@marvell.com>,
Thomas Gleixner <tglx@linutronix.de>,
James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>
Subject: Re: [PATCH v5 20/23] KVM: arm64: GICv4.1: Plumb SGI implementation selection in the distributor
Date: Fri, 20 Mar 2020 09:46:41 +0000 [thread overview]
Message-ID: <dfaf8a1b7c7fd8b769a244a8a779d952@kernel.org> (raw)
In-Reply-To: <e60578b5-910c-0355-d231-29322900679d@redhat.com>
On 2020-03-20 07:59, Auger Eric wrote:
> Hi Zenghui,
>
> On 3/20/20 4:08 AM, Zenghui Yu wrote:
>> On 2020/3/20 4:38, Auger Eric wrote:
>>> Hi Marc,
>>> On 3/19/20 1:10 PM, Marc Zyngier wrote:
>>>> Hi Zenghui,
>>>>
>>>> On 2020-03-18 06:34, Zenghui Yu wrote:
>>>>> Hi Marc,
>>>>>
>>>>> On 2020/3/5 4:33, Marc Zyngier wrote:
>>>>>> The GICv4.1 architecture gives the hypervisor the option to let
>>>>>> the guest choose whether it wants the good old SGIs with an
>>>>>> active state, or the new, HW-based ones that do not have one.
>>>>>>
>>>>>> For this, plumb the configuration of SGIs into the GICv3 MMIO
>>>>>> handling, present the GICD_TYPER2.nASSGIcap to the guest,
>>>>>> and handle the GICD_CTLR.nASSGIreq setting.
>>>>>>
>>>>>> In order to be able to deal with the restore of a guest, also
>>>>>> apply the GICD_CTLR.nASSGIreq setting at first run so that we
>>>>>> can move the restored SGIs to the HW if that's what the guest
>>>>>> had selected in a previous life.
>>>>>
>>>>> I'm okay with the restore path. But it seems that we still fail to
>>>>> save the pending state of vSGI - software pending_latch of HW-based
>>>>> vSGIs will not be updated (and always be false) because we directly
>>>>> inject them through ITS, so vgic_v3_uaccess_read_pending() can't
>>>>> tell the correct pending state to user-space (the correct one
>>>>> should
>>>>> be latched in HW).
>>>>>
>>>>> It would be good if we can sync the hardware state into
>>>>> pending_latch
>>>>> at an appropriate time (just before save), but not sure if we
>>>>> can...
>>>>
>>>> The problem is to find the "appropriate time". It would require to
>>>> define
>>>> a point in the save sequence where we transition the state from HW
>>>> to
>>>> SW. I'm not keen on adding more state than we already have.
>>>
>>> may be we could use a dedicated device group/attr as we have for the
>>> ITS
>>> save tables? the user space would choose.
>>
>> It means that userspace will be aware of some form of GICv4.1 details
>> (e.g., get/set vSGI state at HW level) that KVM has implemented.
>> Is it something that userspace required to know? I'm open to this ;-)
> Not sure we would be obliged to expose fine details. This could be a
> generic save/restore device group/attr whose implementation at KVM
> level
> could differ depending on the version being implemented, no?
What prevents us from hooking this synchronization to the current
behaviour
of KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES? After all, this is already the
point
where we synchronize the KVM view of the pending state with userspace.
Here, it's just a matter of picking the information from some other
place
(i.e. the host's virtual pending table).
The thing we need though is the guarantee that the guest isn't going to
get more vLPIs at that stage, as they would be lost. This effectively
assumes that we can also save/restore the state of the signalling
devices,
and I don't know if we're quite there yet.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jason Cooper <jason@lakedaemon.net>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Robert Richter <rrichter@marvell.com>,
Thomas Gleixner <tglx@linutronix.de>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 20/23] KVM: arm64: GICv4.1: Plumb SGI implementation selection in the distributor
Date: Fri, 20 Mar 2020 09:46:41 +0000 [thread overview]
Message-ID: <dfaf8a1b7c7fd8b769a244a8a779d952@kernel.org> (raw)
In-Reply-To: <e60578b5-910c-0355-d231-29322900679d@redhat.com>
On 2020-03-20 07:59, Auger Eric wrote:
> Hi Zenghui,
>
> On 3/20/20 4:08 AM, Zenghui Yu wrote:
>> On 2020/3/20 4:38, Auger Eric wrote:
>>> Hi Marc,
>>> On 3/19/20 1:10 PM, Marc Zyngier wrote:
>>>> Hi Zenghui,
>>>>
>>>> On 2020-03-18 06:34, Zenghui Yu wrote:
>>>>> Hi Marc,
>>>>>
>>>>> On 2020/3/5 4:33, Marc Zyngier wrote:
>>>>>> The GICv4.1 architecture gives the hypervisor the option to let
>>>>>> the guest choose whether it wants the good old SGIs with an
>>>>>> active state, or the new, HW-based ones that do not have one.
>>>>>>
>>>>>> For this, plumb the configuration of SGIs into the GICv3 MMIO
>>>>>> handling, present the GICD_TYPER2.nASSGIcap to the guest,
>>>>>> and handle the GICD_CTLR.nASSGIreq setting.
>>>>>>
>>>>>> In order to be able to deal with the restore of a guest, also
>>>>>> apply the GICD_CTLR.nASSGIreq setting at first run so that we
>>>>>> can move the restored SGIs to the HW if that's what the guest
>>>>>> had selected in a previous life.
>>>>>
>>>>> I'm okay with the restore path. But it seems that we still fail to
>>>>> save the pending state of vSGI - software pending_latch of HW-based
>>>>> vSGIs will not be updated (and always be false) because we directly
>>>>> inject them through ITS, so vgic_v3_uaccess_read_pending() can't
>>>>> tell the correct pending state to user-space (the correct one
>>>>> should
>>>>> be latched in HW).
>>>>>
>>>>> It would be good if we can sync the hardware state into
>>>>> pending_latch
>>>>> at an appropriate time (just before save), but not sure if we
>>>>> can...
>>>>
>>>> The problem is to find the "appropriate time". It would require to
>>>> define
>>>> a point in the save sequence where we transition the state from HW
>>>> to
>>>> SW. I'm not keen on adding more state than we already have.
>>>
>>> may be we could use a dedicated device group/attr as we have for the
>>> ITS
>>> save tables? the user space would choose.
>>
>> It means that userspace will be aware of some form of GICv4.1 details
>> (e.g., get/set vSGI state at HW level) that KVM has implemented.
>> Is it something that userspace required to know? I'm open to this ;-)
> Not sure we would be obliged to expose fine details. This could be a
> generic save/restore device group/attr whose implementation at KVM
> level
> could differ depending on the version being implemented, no?
What prevents us from hooking this synchronization to the current
behaviour
of KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES? After all, this is already the
point
where we synchronize the KVM view of the pending state with userspace.
Here, it's just a matter of picking the information from some other
place
(i.e. the host's virtual pending table).
The thing we need though is the guarantee that the guest isn't going to
get more vLPIs at that stage, as they would be lost. This effectively
assumes that we can also save/restore the state of the signalling
devices,
and I don't know if we're quite there yet.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Auger Eric <eric.auger@redhat.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Jason Cooper <jason@lakedaemon.net>,
kvm@vger.kernel.org, Suzuki K Poulose <suzuki.poulose@arm.com>,
linux-kernel@vger.kernel.org,
Robert Richter <rrichter@marvell.com>,
James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Thomas Gleixner <tglx@linutronix.de>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 20/23] KVM: arm64: GICv4.1: Plumb SGI implementation selection in the distributor
Date: Fri, 20 Mar 2020 09:46:41 +0000 [thread overview]
Message-ID: <dfaf8a1b7c7fd8b769a244a8a779d952@kernel.org> (raw)
In-Reply-To: <e60578b5-910c-0355-d231-29322900679d@redhat.com>
On 2020-03-20 07:59, Auger Eric wrote:
> Hi Zenghui,
>
> On 3/20/20 4:08 AM, Zenghui Yu wrote:
>> On 2020/3/20 4:38, Auger Eric wrote:
>>> Hi Marc,
>>> On 3/19/20 1:10 PM, Marc Zyngier wrote:
>>>> Hi Zenghui,
>>>>
>>>> On 2020-03-18 06:34, Zenghui Yu wrote:
>>>>> Hi Marc,
>>>>>
>>>>> On 2020/3/5 4:33, Marc Zyngier wrote:
>>>>>> The GICv4.1 architecture gives the hypervisor the option to let
>>>>>> the guest choose whether it wants the good old SGIs with an
>>>>>> active state, or the new, HW-based ones that do not have one.
>>>>>>
>>>>>> For this, plumb the configuration of SGIs into the GICv3 MMIO
>>>>>> handling, present the GICD_TYPER2.nASSGIcap to the guest,
>>>>>> and handle the GICD_CTLR.nASSGIreq setting.
>>>>>>
>>>>>> In order to be able to deal with the restore of a guest, also
>>>>>> apply the GICD_CTLR.nASSGIreq setting at first run so that we
>>>>>> can move the restored SGIs to the HW if that's what the guest
>>>>>> had selected in a previous life.
>>>>>
>>>>> I'm okay with the restore path. But it seems that we still fail to
>>>>> save the pending state of vSGI - software pending_latch of HW-based
>>>>> vSGIs will not be updated (and always be false) because we directly
>>>>> inject them through ITS, so vgic_v3_uaccess_read_pending() can't
>>>>> tell the correct pending state to user-space (the correct one
>>>>> should
>>>>> be latched in HW).
>>>>>
>>>>> It would be good if we can sync the hardware state into
>>>>> pending_latch
>>>>> at an appropriate time (just before save), but not sure if we
>>>>> can...
>>>>
>>>> The problem is to find the "appropriate time". It would require to
>>>> define
>>>> a point in the save sequence where we transition the state from HW
>>>> to
>>>> SW. I'm not keen on adding more state than we already have.
>>>
>>> may be we could use a dedicated device group/attr as we have for the
>>> ITS
>>> save tables? the user space would choose.
>>
>> It means that userspace will be aware of some form of GICv4.1 details
>> (e.g., get/set vSGI state at HW level) that KVM has implemented.
>> Is it something that userspace required to know? I'm open to this ;-)
> Not sure we would be obliged to expose fine details. This could be a
> generic save/restore device group/attr whose implementation at KVM
> level
> could differ depending on the version being implemented, no?
What prevents us from hooking this synchronization to the current
behaviour
of KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES? After all, this is already the
point
where we synchronize the KVM view of the pending state with userspace.
Here, it's just a matter of picking the information from some other
place
(i.e. the host's virtual pending table).
The thing we need though is the guarantee that the guest isn't going to
get more vLPIs at that stage, as they would be lost. This effectively
assumes that we can also save/restore the state of the signalling
devices,
and I don't know if we're quite there yet.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-20 9:46 UTC|newest]
Thread overview: 312+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-04 20:33 [PATCH v5 00/23] irqchip/gic-v4: GICv4.1 architecture support Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 01/23] irqchip/gic-v3: Use SGIs without active state if offered Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 6:30 ` Zenghui Yu
2020-03-12 6:30 ` Zenghui Yu
2020-03-12 6:30 ` Zenghui Yu
2020-03-12 9:28 ` Marc Zyngier
2020-03-12 9:28 ` Marc Zyngier
2020-03-12 9:28 ` Marc Zyngier
2020-03-12 12:05 ` Marc Zyngier
2020-03-12 12:05 ` Marc Zyngier
2020-03-12 12:05 ` Marc Zyngier
2020-03-13 1:39 ` Zenghui Yu
2020-03-13 1:39 ` Zenghui Yu
2020-03-13 1:39 ` Zenghui Yu
2020-03-12 17:16 ` Auger Eric
2020-03-12 17:16 ` Auger Eric
2020-03-12 17:16 ` Auger Eric
2020-03-12 17:23 ` Marc Zyngier
2020-03-12 17:23 ` Marc Zyngier
2020-03-12 17:23 ` Marc Zyngier
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 02/23] irqchip/gic-v4.1: Skip absent CPUs while iterating over redistributors Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-16 17:10 ` Auger Eric
2020-03-16 17:10 ` Auger Eric
2020-03-16 17:10 ` Auger Eric
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 03/23] irqchip/gic-v4.1: Ensure mutual exclusion between vPE affinity change and RD access Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 6:56 ` Zenghui Yu
2020-03-12 6:56 ` Zenghui Yu
2020-03-12 6:56 ` Zenghui Yu
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 04/23] irqchip/gic-v4.1: Wait for completion of redistributor's INVALL operation Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-20 14:23 ` Auger Eric
2020-03-20 14:23 ` Auger Eric
2020-03-20 14:23 ` Auger Eric
2020-03-04 20:33 ` [PATCH v5 05/23] irqchip/gic-v4.1: Ensure mutual exclusion betwen invalidations on the same RD Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 7:11 ` Zenghui Yu
2020-03-12 7:11 ` Zenghui Yu
2020-03-12 7:11 ` Zenghui Yu
2020-03-20 14:23 ` Auger Eric
2020-03-20 14:23 ` Auger Eric
2020-03-20 14:23 ` Auger Eric
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 06/23] irqchip/gic-v4.1: Advertise support v4.1 to KVM Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-16 17:10 ` Auger Eric
2020-03-16 17:10 ` Auger Eric
2020-03-16 17:10 ` Auger Eric
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 07/23] irqchip/gic-v4.1: Map the ITS SGIR register page Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-16 17:10 ` Auger Eric
2020-03-16 17:10 ` Auger Eric
2020-03-16 17:10 ` Auger Eric
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 08/23] irqchip/gic-v4.1: Plumb skeletal VSGI irqchip Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-16 17:10 ` Auger Eric
2020-03-16 17:10 ` Auger Eric
2020-03-16 17:10 ` Auger Eric
2020-03-19 10:03 ` Marc Zyngier
2020-03-19 10:03 ` Marc Zyngier
2020-03-19 10:03 ` Marc Zyngier
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 09/23] irqchip/gic-v4.1: Add initial SGI configuration Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-16 17:53 ` Auger Eric
2020-03-16 17:53 ` Auger Eric
2020-03-16 17:53 ` Auger Eric
2020-03-17 2:02 ` Zenghui Yu
2020-03-17 2:02 ` Zenghui Yu
2020-03-17 2:02 ` Zenghui Yu
2020-03-17 8:36 ` Auger Eric
2020-03-17 8:36 ` Auger Eric
2020-03-17 8:36 ` Auger Eric
2020-03-19 10:20 ` Marc Zyngier
2020-03-19 10:20 ` Marc Zyngier
2020-03-19 10:20 ` Marc Zyngier
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 10/23] irqchip/gic-v4.1: Plumb mask/unmask SGI callbacks Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-16 18:15 ` Auger Eric
2020-03-16 18:15 ` Auger Eric
2020-03-16 18:15 ` Auger Eric
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 11/23] irqchip/gic-v4.1: Plumb get/set_irqchip_state " Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 7:41 ` Zenghui Yu
2020-03-12 7:41 ` Zenghui Yu
2020-03-12 7:41 ` Zenghui Yu
2020-03-16 21:43 ` Auger Eric
2020-03-16 21:43 ` Auger Eric
2020-03-16 21:43 ` Auger Eric
2020-03-19 10:27 ` Marc Zyngier
2020-03-19 10:27 ` Marc Zyngier
2020-03-19 10:27 ` Marc Zyngier
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 12/23] irqchip/gic-v4.1: Plumb set_vcpu_affinity " Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-17 10:35 ` Auger Eric
2020-03-17 10:35 ` Auger Eric
2020-03-17 10:35 ` Auger Eric
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 13/23] irqchip/gic-v4.1: Move doorbell management to the GICv4 abstraction layer Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 8:20 ` Zenghui Yu
2020-03-12 8:20 ` Zenghui Yu
2020-03-12 8:20 ` Zenghui Yu
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 14/23] irqchip/gic-v4.1: Add VSGI allocation/teardown Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 8:06 ` Zenghui Yu
2020-03-12 8:06 ` Zenghui Yu
2020-03-12 8:06 ` Zenghui Yu
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 15/23] irqchip/gic-v4.1: Add VSGI property setup Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 8:09 ` Zenghui Yu
2020-03-12 8:09 ` Zenghui Yu
2020-03-12 8:09 ` Zenghui Yu
2020-03-17 10:30 ` Auger Eric
2020-03-17 10:30 ` Auger Eric
2020-03-17 10:30 ` Auger Eric
2020-03-19 10:57 ` Marc Zyngier
2020-03-19 10:57 ` Marc Zyngier
2020-03-19 10:57 ` Marc Zyngier
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 16/23] irqchip/gic-v4.1: Eagerly vmap vPEs Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 8:12 ` Zenghui Yu
2020-03-12 8:12 ` Zenghui Yu
2020-03-12 8:12 ` Zenghui Yu
2020-03-17 2:49 ` Zenghui Yu
2020-03-17 2:49 ` Zenghui Yu
2020-03-17 2:49 ` Zenghui Yu
2020-03-19 10:55 ` Marc Zyngier
2020-03-19 10:55 ` Marc Zyngier
2020-03-19 10:55 ` Marc Zyngier
2020-03-20 2:31 ` Zenghui Yu
2020-03-20 2:31 ` Zenghui Yu
2020-03-20 2:31 ` Zenghui Yu
2020-03-29 20:26 ` [tip: irq/core] " tip-bot2 for Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 17/23] KVM: arm64: GICv4.1: Let doorbells be auto-enabled Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-12 8:15 ` Zenghui Yu
2020-03-12 8:15 ` Zenghui Yu
2020-03-12 8:15 ` Zenghui Yu
2020-03-17 11:04 ` Auger Eric
2020-03-17 11:04 ` Auger Eric
2020-03-17 11:04 ` Auger Eric
2020-03-04 20:33 ` [PATCH v5 18/23] KVM: arm64: GICv4.1: Add direct injection capability to SGI registers Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-18 3:28 ` Zenghui Yu
2020-03-18 3:28 ` Zenghui Yu
2020-03-18 3:28 ` Zenghui Yu
2020-03-20 8:11 ` Auger Eric
2020-03-20 8:11 ` Auger Eric
2020-03-20 8:11 ` Auger Eric
2020-03-20 10:05 ` Marc Zyngier
2020-03-20 10:05 ` Marc Zyngier
2020-03-20 10:05 ` Marc Zyngier
2020-03-20 10:56 ` Auger Eric
2020-03-20 10:56 ` Auger Eric
2020-03-20 10:56 ` Auger Eric
2020-03-04 20:33 ` [PATCH v5 19/23] KVM: arm64: GICv4.1: Allow SGIs to switch between HW and SW interrupts Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-19 16:16 ` Auger Eric
2020-03-19 16:16 ` Auger Eric
2020-03-19 16:16 ` Auger Eric
2020-03-19 19:52 ` Marc Zyngier
2020-03-19 19:52 ` Marc Zyngier
2020-03-19 19:52 ` Marc Zyngier
2020-03-19 20:13 ` Auger Eric
2020-03-19 20:13 ` Auger Eric
2020-03-19 20:13 ` Auger Eric
2020-03-20 9:17 ` Marc Zyngier
2020-03-20 9:17 ` Marc Zyngier
2020-03-20 9:17 ` Marc Zyngier
2020-03-20 4:22 ` Zenghui Yu
2020-03-20 4:22 ` Zenghui Yu
2020-03-20 4:22 ` Zenghui Yu
2020-03-04 20:33 ` [PATCH v5 20/23] KVM: arm64: GICv4.1: Plumb SGI implementation selection in the distributor Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-18 6:34 ` Zenghui Yu
2020-03-18 6:34 ` Zenghui Yu
2020-03-18 6:34 ` Zenghui Yu
2020-03-19 12:10 ` Marc Zyngier
2020-03-19 12:10 ` Marc Zyngier
2020-03-19 12:10 ` Marc Zyngier
2020-03-19 20:38 ` Auger Eric
2020-03-19 20:38 ` Auger Eric
2020-03-19 20:38 ` Auger Eric
2020-03-20 3:08 ` Zenghui Yu
2020-03-20 3:08 ` Zenghui Yu
2020-03-20 3:08 ` Zenghui Yu
2020-03-20 7:59 ` Auger Eric
2020-03-20 7:59 ` Auger Eric
2020-03-20 7:59 ` Auger Eric
2020-03-20 9:46 ` Marc Zyngier [this message]
2020-03-20 9:46 ` Marc Zyngier
2020-03-20 9:46 ` Marc Zyngier
2020-03-20 11:09 ` Auger Eric
2020-03-20 11:09 ` Auger Eric
2020-03-20 11:09 ` Auger Eric
2020-03-20 11:20 ` Marc Zyngier
2020-03-20 11:20 ` Marc Zyngier
2020-03-20 11:20 ` Marc Zyngier
2020-03-20 3:53 ` Zenghui Yu
2020-03-20 3:53 ` Zenghui Yu
2020-03-20 3:53 ` Zenghui Yu
2020-03-20 9:01 ` Marc Zyngier
2020-03-20 9:01 ` Marc Zyngier
2020-03-20 9:01 ` Marc Zyngier
2020-03-23 8:11 ` Zenghui Yu
2020-03-23 8:11 ` Zenghui Yu
2020-03-23 8:11 ` Zenghui Yu
2020-03-23 8:25 ` Marc Zyngier
2020-03-23 8:25 ` Marc Zyngier
2020-03-23 8:25 ` Marc Zyngier
2020-03-23 12:40 ` Zenghui Yu
2020-03-23 12:40 ` Zenghui Yu
2020-03-23 12:40 ` Zenghui Yu
2020-03-04 20:33 ` [PATCH v5 21/23] KVM: arm64: GICv4.1: Reload VLPI configuration on distributor enable/disable Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-18 3:17 ` Zenghui Yu
2020-03-18 3:17 ` Zenghui Yu
2020-03-18 3:17 ` Zenghui Yu
2020-03-19 12:18 ` Marc Zyngier
2020-03-19 12:18 ` Marc Zyngier
2020-03-19 12:18 ` Marc Zyngier
2020-03-04 20:33 ` [PATCH v5 22/23] KVM: arm64: GICv4.1: Allow non-trapping WFI when using HW SGIs Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-20 4:23 ` Zenghui Yu
2020-03-20 4:23 ` Zenghui Yu
2020-03-20 4:23 ` Zenghui Yu
2020-03-20 8:12 ` Auger Eric
2020-03-20 8:12 ` Auger Eric
2020-03-20 8:12 ` Auger Eric
2020-03-04 20:33 ` [PATCH v5 23/23] KVM: arm64: GICv4.1: Expose HW-based SGIs in debugfs Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-04 20:33 ` Marc Zyngier
2020-03-18 3:19 ` Zenghui Yu
2020-03-18 3:19 ` Zenghui Yu
2020-03-18 3:19 ` Zenghui Yu
2020-03-19 15:05 ` Auger Eric
2020-03-19 15:05 ` Auger Eric
2020-03-19 15:05 ` Auger Eric
2020-03-19 15:21 ` Marc Zyngier
2020-03-19 15:21 ` Marc Zyngier
2020-03-19 15:21 ` Marc Zyngier
2020-03-19 15:43 ` Auger Eric
2020-03-19 15:43 ` Auger Eric
2020-03-19 15:43 ` Auger Eric
2020-03-19 16:16 ` Marc Zyngier
2020-03-19 16:16 ` Marc Zyngier
2020-03-19 16:16 ` Marc Zyngier
2020-03-19 16:17 ` Auger Eric
2020-03-19 16:17 ` Auger Eric
2020-03-19 16:17 ` Auger Eric
2020-03-20 4:38 ` Zenghui Yu
2020-03-20 4:38 ` Zenghui Yu
2020-03-20 4:38 ` Zenghui Yu
2020-03-20 9:09 ` Marc Zyngier
2020-03-20 9:09 ` Marc Zyngier
2020-03-20 9:09 ` Marc Zyngier
2020-03-20 11:35 ` Zenghui Yu
2020-03-20 11:35 ` Zenghui Yu
2020-03-20 11:35 ` Zenghui Yu
2020-03-20 11:46 ` Marc Zyngier
2020-03-20 11:46 ` Marc Zyngier
2020-03-20 11:46 ` Marc Zyngier
2020-03-20 12:09 ` Zenghui Yu
2020-03-20 12:09 ` Zenghui Yu
2020-03-20 12:09 ` Zenghui Yu
2020-03-05 3:39 ` [PATCH v5 00/23] irqchip/gic-v4: GICv4.1 architecture support Zenghui Yu
2020-03-05 3:39 ` Zenghui Yu
2020-03-05 3:39 ` Zenghui Yu
2020-03-09 8:17 ` Zenghui Yu
2020-03-09 8:17 ` Zenghui Yu
2020-03-09 8:17 ` Zenghui Yu
2020-03-09 8:46 ` Marc Zyngier
2020-03-09 8:46 ` Marc Zyngier
2020-03-09 8:46 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dfaf8a1b7c7fd8b769a244a8a779d952@kernel.org \
--to=maz@kernel.org \
--cc=eric.auger@redhat.com \
--cc=james.morse@arm.com \
--cc=jason@lakedaemon.net \
--cc=julien.thierry.kdev@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=rrichter@marvell.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.