All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 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.