From: Shenming Lu <lushenming@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Eric Auger <eric.auger@redhat.com>,
<linux-arm-kernel@lists.infradead.org>,
<kvmarm@lists.cs.columbia.edu>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Christoffer Dall <christoffer.dall@arm.com>,
Alex Williamson <alex.williamson@redhat.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
Cornelia Huck <cohuck@redhat.com>, Neo Jia <cjia@nvidia.com>,
<wanghaibin.wang@huawei.com>, <yuzenghui@huawei.com>
Subject: Re: [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side
Date: Tue, 1 Dec 2020 19:40:14 +0800 [thread overview]
Message-ID: <9b80d460-e149-20c8-e9b3-e695310b4ed1@huawei.com> (raw)
In-Reply-To: <2ad38077300bdcaedd2e3b073cd36743@kernel.org>
On 2020/12/1 18:55, Marc Zyngier wrote:
> On 2020-11-30 07:23, Shenming Lu wrote:
>
> Hi Shenming,
>
>> We are pondering over this problem these days, but still don't get a
>> good solution...
>> Could you give us some advice on this?
>>
>> Or could we move the restoring of the pending states (include the sync
>> from guest RAM and the transfer to HW) to the GIC VM state change handler,
>> which is completely corresponding to save_pending_tables (more symmetric?)
>> and don't expose GICv4...
>
> What is "the GIC VM state change handler"? Is that a QEMU thing?
Yeah, it is a a QEMU thing...
> We don't really have that concept in KVM, so I'd appreciate if you could
> be a bit more explicit on this.
My thought is to add a new interface (to QEMU) for the restoring of the pending
states, which is completely corresponding to KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES...
And it is called from the GIC VM state change handler in QEMU, which is happening
after the restoring (call kvm_vgic_v4_set_forwarding()) but before the starting
(running) of the VFIO device.
Thanks,
Shenming
>
> Thanks,
>
> M.
WARNING: multiple messages have this Message-ID (diff)
From: Shenming Lu <lushenming@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Neo Jia <cjia@nvidia.com>,
kvm@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
linux-kernel@vger.kernel.org,
Kirti Wankhede <kwankhede@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side
Date: Tue, 1 Dec 2020 19:40:14 +0800 [thread overview]
Message-ID: <9b80d460-e149-20c8-e9b3-e695310b4ed1@huawei.com> (raw)
In-Reply-To: <2ad38077300bdcaedd2e3b073cd36743@kernel.org>
On 2020/12/1 18:55, Marc Zyngier wrote:
> On 2020-11-30 07:23, Shenming Lu wrote:
>
> Hi Shenming,
>
>> We are pondering over this problem these days, but still don't get a
>> good solution...
>> Could you give us some advice on this?
>>
>> Or could we move the restoring of the pending states (include the sync
>> from guest RAM and the transfer to HW) to the GIC VM state change handler,
>> which is completely corresponding to save_pending_tables (more symmetric?)
>> and don't expose GICv4...
>
> What is "the GIC VM state change handler"? Is that a QEMU thing?
Yeah, it is a a QEMU thing...
> We don't really have that concept in KVM, so I'd appreciate if you could
> be a bit more explicit on this.
My thought is to add a new interface (to QEMU) for the restoring of the pending
states, which is completely corresponding to KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES...
And it is called from the GIC VM state change handler in QEMU, which is happening
after the restoring (call kvm_vgic_v4_set_forwarding()) but before the starting
(running) of the VFIO device.
Thanks,
Shenming
>
> Thanks,
>
> M.
_______________________________________________
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: Shenming Lu <lushenming@huawei.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Neo Jia <cjia@nvidia.com>,
kvm@vger.kernel.org, Suzuki K Poulose <suzuki.poulose@arm.com>,
Cornelia Huck <cohuck@redhat.com>,
linux-kernel@vger.kernel.org,
Kirti Wankhede <kwankhede@nvidia.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Eric Auger <eric.auger@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
James Morse <james.morse@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
yuzenghui@huawei.com, wanghaibin.wang@huawei.com,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side
Date: Tue, 1 Dec 2020 19:40:14 +0800 [thread overview]
Message-ID: <9b80d460-e149-20c8-e9b3-e695310b4ed1@huawei.com> (raw)
In-Reply-To: <2ad38077300bdcaedd2e3b073cd36743@kernel.org>
On 2020/12/1 18:55, Marc Zyngier wrote:
> On 2020-11-30 07:23, Shenming Lu wrote:
>
> Hi Shenming,
>
>> We are pondering over this problem these days, but still don't get a
>> good solution...
>> Could you give us some advice on this?
>>
>> Or could we move the restoring of the pending states (include the sync
>> from guest RAM and the transfer to HW) to the GIC VM state change handler,
>> which is completely corresponding to save_pending_tables (more symmetric?)
>> and don't expose GICv4...
>
> What is "the GIC VM state change handler"? Is that a QEMU thing?
Yeah, it is a a QEMU thing...
> We don't really have that concept in KVM, so I'd appreciate if you could
> be a bit more explicit on this.
My thought is to add a new interface (to QEMU) for the restoring of the pending
states, which is completely corresponding to KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES...
And it is called from the GIC VM state change handler in QEMU, which is happening
after the restoring (call kvm_vgic_v4_set_forwarding()) but before the starting
(running) of the VFIO device.
Thanks,
Shenming
>
> Thanks,
>
> M.
_______________________________________________
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-12-01 11:41 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-23 6:54 [RFC PATCH v1 0/4] KVM: arm64: Add VLPI migration support on GICv4.1 Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 6:54 ` [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 9:01 ` Marc Zyngier
2020-11-23 9:01 ` Marc Zyngier
2020-11-23 9:01 ` Marc Zyngier
2020-11-24 7:38 ` Shenming Lu
2020-11-24 7:38 ` Shenming Lu
2020-11-24 7:38 ` Shenming Lu
2020-11-24 8:08 ` Marc Zyngier
2020-11-24 8:08 ` Marc Zyngier
2020-11-24 8:08 ` Marc Zyngier
2020-11-28 7:19 ` luojiaxing
2020-11-28 7:19 ` luojiaxing
2020-11-28 7:19 ` luojiaxing
2020-11-28 10:18 ` Marc Zyngier
2020-11-28 10:18 ` Marc Zyngier
2020-11-28 10:18 ` Marc Zyngier
2020-12-01 9:38 ` luojiaxing
2020-12-01 9:38 ` luojiaxing
2020-12-01 9:38 ` luojiaxing
2020-12-01 10:58 ` Marc Zyngier
2020-12-01 10:58 ` Marc Zyngier
2020-12-01 10:58 ` Marc Zyngier
2020-11-23 6:54 ` [RFC PATCH v1 2/4] KVM: arm64: GICv4.1: Try to save hw pending state in save_pending_tables Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 9:18 ` Marc Zyngier
2020-11-23 9:18 ` Marc Zyngier
2020-11-23 9:18 ` Marc Zyngier
2020-11-24 7:40 ` Shenming Lu
2020-11-24 7:40 ` Shenming Lu
2020-11-24 7:40 ` Shenming Lu
2020-11-24 8:26 ` Marc Zyngier
2020-11-24 8:26 ` Marc Zyngier
2020-11-24 8:26 ` Marc Zyngier
2020-11-24 13:10 ` Shenming Lu
2020-11-24 13:10 ` Shenming Lu
2020-11-24 13:10 ` Shenming Lu
2020-11-23 6:54 ` [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 9:27 ` Marc Zyngier
2020-11-23 9:27 ` Marc Zyngier
2020-11-23 9:27 ` Marc Zyngier
2020-11-24 8:10 ` Shenming Lu
2020-11-24 8:10 ` Shenming Lu
2020-11-24 8:10 ` Shenming Lu
2020-11-24 8:44 ` Marc Zyngier
2020-11-24 8:44 ` Marc Zyngier
2020-11-24 8:44 ` Marc Zyngier
2020-11-24 13:12 ` Shenming Lu
2020-11-24 13:12 ` Shenming Lu
2020-11-24 13:12 ` Shenming Lu
2020-11-30 7:23 ` Shenming Lu
2020-11-30 7:23 ` Shenming Lu
2020-11-30 7:23 ` Shenming Lu
2020-12-01 10:55 ` Marc Zyngier
2020-12-01 10:55 ` Marc Zyngier
2020-12-01 10:55 ` Marc Zyngier
2020-12-01 11:40 ` Shenming Lu [this message]
2020-12-01 11:40 ` Shenming Lu
2020-12-01 11:40 ` Shenming Lu
2020-12-01 11:50 ` Marc Zyngier
2020-12-01 11:50 ` Marc Zyngier
2020-12-01 11:50 ` Marc Zyngier
2020-12-01 12:15 ` Shenming Lu
2020-12-01 12:15 ` Shenming Lu
2020-12-01 12:15 ` Shenming Lu
2020-12-08 8:25 ` Shenming Lu
2020-12-08 8:25 ` Shenming Lu
2020-12-08 8:25 ` Shenming Lu
2020-12-16 10:35 ` Auger Eric
2020-12-16 10:35 ` Auger Eric
2020-12-16 10:35 ` Auger Eric
2020-12-17 4:19 ` Shenming Lu
2020-12-17 4:19 ` Shenming Lu
2020-12-17 4:19 ` Shenming Lu
2020-11-23 6:54 ` [RFC PATCH v1 4/4] KVM: arm64: GICv4.1: Give a chance to save VLPI's pending state Shenming Lu
2020-11-23 6:54 ` Shenming Lu
2020-11-23 6:54 ` Shenming Lu
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=9b80d460-e149-20c8-e9b3-e695310b4ed1@huawei.com \
--to=lushenming@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=christoffer.dall@arm.com \
--cc=cjia@nvidia.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=james.morse@arm.com \
--cc=julien.thierry.kdev@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=kwankhede@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=wanghaibin.wang@huawei.com \
--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.