From: Marc Zyngier <maz@kernel.org>
To: Kunkun Jiang <jiangkunkun@huawei.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
<linux-arm-kernel@lists.infradead.org>, <kvmarm@lists.linux.dev>,
<wanghaibin.wang@huawei.com>, <lishusen2@huawei.com>,
Eric Auger <eauger@redhat.com>
Subject: Re: [PATCH] KVM: arm64: vgic-its: clear dte when mapd unmaps a device
Date: Thu, 13 Jun 2024 15:44:06 +0100 [thread overview]
Message-ID: <86v82ckimh.wl-maz@kernel.org> (raw)
In-Reply-To: <20240613093811.710-1-jiangkunkun@huawei.com>
On Thu, 13 Jun 2024 10:38:11 +0100,
Kunkun Jiang <jiangkunkun@huawei.com> wrote:
>
> vgic_its_save_device_tables will traverse its->device_list to
> save dte for each device. vgic_its_restore_device_tables will
> traverse each entry of device table and check if it is valid.
> Restore if valid.
>
> But when mapd unmaps a devices, we do not invalidate the
> corresponding dte. In the scenario of continuous save
> and restore, there may be a situation where a device's dte
> is not saved but is restored. This is unreasonable and may
> cause restore to fail. This patch clears the corresponding
> dte when mapd unmaps a device.
>
> Singed-off-by: Shusen Li <lishusen2@huawei.com>
^^^^^^^^^^^^^ This isn't a valid tag!
> Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Something is wrong. Either Shusen Li is the author and you are merely
posting it, in which case there should be a 'From' line in the commit
message, or you are co-authors and there should be a 'Co-developed-by'
right after Shusen Li's SoB.
Please read Documentation/process/submitting-patches.rst for the
details.
> ---
> arch/arm64/kvm/vgic/vgic-its.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
> index 40bb43f20bf3..dd5fba1e8ba3 100644
> --- a/arch/arm64/kvm/vgic/vgic-its.c
> +++ b/arch/arm64/kvm/vgic/vgic-its.c
> @@ -1140,8 +1140,12 @@ static int vgic_its_cmd_handle_mapd(struct kvm *kvm, struct vgic_its *its,
> u8 num_eventid_bits = its_cmd_get_size(its_cmd);
> gpa_t itt_addr = its_cmd_get_ittaddr(its_cmd);
> struct its_device *device;
> + gpa_t gpa;
> + const struct vgic_its_abi *abi;
> + int dte_esz;
> + u64 val;
Aside from 'gpa', all the extra variables should be moved into the
!valid block. And it would be nicer if this variable was called
something more descriptive.
>
> - if (!vgic_its_check_id(its, its->baser_device_table, device_id, NULL))
> + if (!vgic_its_check_id(its, its->baser_device_table, device_id, &gpa))
> return E_ITS_MAPD_DEVICE_OOR;
>
> if (valid && num_eventid_bits > VITS_TYPER_IDBITS)
> @@ -1161,8 +1165,13 @@ static int vgic_its_cmd_handle_mapd(struct kvm *kvm, struct vgic_its *its,
> * The spec does not say whether unmapping a not-mapped device
> * is an error, so we are done in any case.
> */
> - if (!valid)
> + if (!valid) {
> + abi = vgic_its_get_abi(its);
> + dte_esz = abi->dte_esz;
> + val = cpu_to_le64(0);
> + vgic_write_guest_lock(kvm, gpa, &val, dte_esz);
This is just a bit wrong:
- you store 0 in a u64 after having (pointlessly) converted it to le64
- you write 'dte_esz' bytes into guest memory, but you don't have any
check whether this is *larger* than the u64 you have passed
Similar issue exists in all the vgic_its_save_*() functions, calling
for a generic fix, as we're just lucky to never have needed a new ABI
so far. At the very least a check that we deal with data that is
exactly 8 bytes.
Also, is the device table the only one that is subject to this
'reload' problem? How about the Collection table?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-06-13 14:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 9:38 [PATCH] KVM: arm64: vgic-its: clear dte when mapd unmaps a device Kunkun Jiang
2024-06-13 14:44 ` Marc Zyngier [this message]
2024-06-18 17:18 ` Eric Auger
2024-06-20 13:32 ` Kunkun Jiang
2024-06-20 13:58 ` Marc Zyngier
2024-06-20 13:18 ` Kunkun Jiang
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=86v82ckimh.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=eauger@redhat.com \
--cc=james.morse@arm.com \
--cc=jiangkunkun@huawei.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lishusen2@huawei.com \
--cc=oliver.upton@linux.dev \
--cc=rdunlap@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=wanghaibin.wang@huawei.com \
--cc=will@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox