From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <yuzenghui@huawei.com>
Cc: andre.przywara@arm.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH] KVM: arm64: vgic-v3: Clear pending bit in guest memory after synchronization
Date: Tue, 31 Mar 2020 09:07:09 +0100 [thread overview]
Message-ID: <20200331090709.17d2087d@why> (raw)
In-Reply-To: <20200331031245.1562-1-yuzenghui@huawei.com>
Hi Zenghui,
On Tue, 31 Mar 2020 11:12:45 +0800
Zenghui Yu <yuzenghui@huawei.com> wrote:
> When LPI support is enabled at redistributor level, VGIC will potentially
> load the correspond LPI penging table and sync it into the pending_latch.
> To avoid keeping the 'consumed' pending bits lying around in guest memory
> (though they're not used), let's clear them after synchronization.
>
> The similar work had been done in vgic_v3_lpi_sync_pending_status().
>
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
> ---
> virt/kvm/arm/vgic/vgic-its.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index d53d34a33e35..905760bfa404 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -435,6 +435,7 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
>
> for (i = 0; i < nr_irqs; i++) {
> int byte_offset, bit_nr;
> + bool status;
>
> byte_offset = intids[i] / BITS_PER_BYTE;
> bit_nr = intids[i] % BITS_PER_BYTE;
> @@ -447,22 +448,32 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
> ret = kvm_read_guest_lock(vcpu->kvm,
> pendbase + byte_offset,
> &pendmask, 1);
> - if (ret) {
> - kfree(intids);
> - return ret;
> - }
> + if (ret)
> + goto out;
> last_byte_offset = byte_offset;
> }
>
> + status = pendmask & (1 << bit_nr);
> +
> irq = vgic_get_irq(vcpu->kvm, NULL, intids[i]);
> raw_spin_lock_irqsave(&irq->irq_lock, flags);
> - irq->pending_latch = pendmask & (1U << bit_nr);
> + irq->pending_latch = status;
> vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> vgic_put_irq(vcpu->kvm, irq);
> +
> + if (status) {
> + /* clear consumed data */
> + pendmask &= ~(1 << bit_nr);
> + ret = kvm_write_guest_lock(vcpu->kvm,
> + pendbase + byte_offset,
> + &pendmask, 1);
> + if (ret)
> + goto out;
> + }
> }
>
> +out:
> kfree(intids);
> -
> return ret;
> }
>
I've been thinking about this, and I wonder why we don't simply clear
the whole pending table instead of carefully wiping it one bit at a
time. My reasoning is that if a LPI isn't mapped, then it cannot be made
pending the first place.
And I think there is a similar issue in vgic_v3_lpi_sync_pending_status().
Why sync something back from the pending table when the LPI wasn't
mapped yet? This seems pretty bizarre, as the GITS_TRANSLATER spec says
that the write to this register is ignored when:
"- The EventID is mapped to an Interrupt Translation Table and the
EventID is within the range specified by MAPD on page 5-107, but the
EventID is unmapped."
(with the added bonus in the form of a type: the first instance of
"EventID" here should obviously be "DeviceID").
What do you think?
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: Zenghui Yu <yuzenghui@huawei.com>
Cc: suzuki.poulose@arm.com, andre.przywara@arm.com,
linux-kernel@vger.kernel.org, eric.auger@redhat.com,
james.morse@arm.com, linux-arm-kernel@lists.infradead.org,
wanghaibin.wang@huawei.com, kvmarm@lists.cs.columbia.edu,
julien.thierry.kdev@gmail.com
Subject: Re: [PATCH] KVM: arm64: vgic-v3: Clear pending bit in guest memory after synchronization
Date: Tue, 31 Mar 2020 09:07:09 +0100 [thread overview]
Message-ID: <20200331090709.17d2087d@why> (raw)
In-Reply-To: <20200331031245.1562-1-yuzenghui@huawei.com>
Hi Zenghui,
On Tue, 31 Mar 2020 11:12:45 +0800
Zenghui Yu <yuzenghui@huawei.com> wrote:
> When LPI support is enabled at redistributor level, VGIC will potentially
> load the correspond LPI penging table and sync it into the pending_latch.
> To avoid keeping the 'consumed' pending bits lying around in guest memory
> (though they're not used), let's clear them after synchronization.
>
> The similar work had been done in vgic_v3_lpi_sync_pending_status().
>
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
> ---
> virt/kvm/arm/vgic/vgic-its.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index d53d34a33e35..905760bfa404 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -435,6 +435,7 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
>
> for (i = 0; i < nr_irqs; i++) {
> int byte_offset, bit_nr;
> + bool status;
>
> byte_offset = intids[i] / BITS_PER_BYTE;
> bit_nr = intids[i] % BITS_PER_BYTE;
> @@ -447,22 +448,32 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
> ret = kvm_read_guest_lock(vcpu->kvm,
> pendbase + byte_offset,
> &pendmask, 1);
> - if (ret) {
> - kfree(intids);
> - return ret;
> - }
> + if (ret)
> + goto out;
> last_byte_offset = byte_offset;
> }
>
> + status = pendmask & (1 << bit_nr);
> +
> irq = vgic_get_irq(vcpu->kvm, NULL, intids[i]);
> raw_spin_lock_irqsave(&irq->irq_lock, flags);
> - irq->pending_latch = pendmask & (1U << bit_nr);
> + irq->pending_latch = status;
> vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> vgic_put_irq(vcpu->kvm, irq);
> +
> + if (status) {
> + /* clear consumed data */
> + pendmask &= ~(1 << bit_nr);
> + ret = kvm_write_guest_lock(vcpu->kvm,
> + pendbase + byte_offset,
> + &pendmask, 1);
> + if (ret)
> + goto out;
> + }
> }
>
> +out:
> kfree(intids);
> -
> return ret;
> }
>
I've been thinking about this, and I wonder why we don't simply clear
the whole pending table instead of carefully wiping it one bit at a
time. My reasoning is that if a LPI isn't mapped, then it cannot be made
pending the first place.
And I think there is a similar issue in vgic_v3_lpi_sync_pending_status().
Why sync something back from the pending table when the LPI wasn't
mapped yet? This seems pretty bizarre, as the GITS_TRANSLATER spec says
that the write to this register is ignored when:
"- The EventID is mapped to an Interrupt Translation Table and the
EventID is within the range specified by MAPD on page 5-107, but the
EventID is unmapped."
(with the added bonus in the form of a type: the first instance of
"EventID" here should obviously be "DeviceID").
What do you think?
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
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <yuzenghui@huawei.com>
Cc: <kvmarm@lists.cs.columbia.edu>, <eric.auger@redhat.com>,
<andre.przywara@arm.com>, <james.morse@arm.com>,
<julien.thierry.kdev@gmail.com>, <suzuki.poulose@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <wanghaibin.wang@huawei.com>
Subject: Re: [PATCH] KVM: arm64: vgic-v3: Clear pending bit in guest memory after synchronization
Date: Tue, 31 Mar 2020 09:07:09 +0100 [thread overview]
Message-ID: <20200331090709.17d2087d@why> (raw)
In-Reply-To: <20200331031245.1562-1-yuzenghui@huawei.com>
Hi Zenghui,
On Tue, 31 Mar 2020 11:12:45 +0800
Zenghui Yu <yuzenghui@huawei.com> wrote:
> When LPI support is enabled at redistributor level, VGIC will potentially
> load the correspond LPI penging table and sync it into the pending_latch.
> To avoid keeping the 'consumed' pending bits lying around in guest memory
> (though they're not used), let's clear them after synchronization.
>
> The similar work had been done in vgic_v3_lpi_sync_pending_status().
>
> Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
> ---
> virt/kvm/arm/vgic/vgic-its.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> index d53d34a33e35..905760bfa404 100644
> --- a/virt/kvm/arm/vgic/vgic-its.c
> +++ b/virt/kvm/arm/vgic/vgic-its.c
> @@ -435,6 +435,7 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
>
> for (i = 0; i < nr_irqs; i++) {
> int byte_offset, bit_nr;
> + bool status;
>
> byte_offset = intids[i] / BITS_PER_BYTE;
> bit_nr = intids[i] % BITS_PER_BYTE;
> @@ -447,22 +448,32 @@ static int its_sync_lpi_pending_table(struct kvm_vcpu *vcpu)
> ret = kvm_read_guest_lock(vcpu->kvm,
> pendbase + byte_offset,
> &pendmask, 1);
> - if (ret) {
> - kfree(intids);
> - return ret;
> - }
> + if (ret)
> + goto out;
> last_byte_offset = byte_offset;
> }
>
> + status = pendmask & (1 << bit_nr);
> +
> irq = vgic_get_irq(vcpu->kvm, NULL, intids[i]);
> raw_spin_lock_irqsave(&irq->irq_lock, flags);
> - irq->pending_latch = pendmask & (1U << bit_nr);
> + irq->pending_latch = status;
> vgic_queue_irq_unlock(vcpu->kvm, irq, flags);
> vgic_put_irq(vcpu->kvm, irq);
> +
> + if (status) {
> + /* clear consumed data */
> + pendmask &= ~(1 << bit_nr);
> + ret = kvm_write_guest_lock(vcpu->kvm,
> + pendbase + byte_offset,
> + &pendmask, 1);
> + if (ret)
> + goto out;
> + }
> }
>
> +out:
> kfree(intids);
> -
> return ret;
> }
>
I've been thinking about this, and I wonder why we don't simply clear
the whole pending table instead of carefully wiping it one bit at a
time. My reasoning is that if a LPI isn't mapped, then it cannot be made
pending the first place.
And I think there is a similar issue in vgic_v3_lpi_sync_pending_status().
Why sync something back from the pending table when the LPI wasn't
mapped yet? This seems pretty bizarre, as the GITS_TRANSLATER spec says
that the write to this register is ignored when:
"- The EventID is mapped to an Interrupt Translation Table and the
EventID is within the range specified by MAPD on page 5-107, but the
EventID is unmapped."
(with the added bonus in the form of a type: the first instance of
"EventID" here should obviously be "DeviceID").
What do you think?
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-03-31 8:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-31 3:12 [PATCH] KVM: arm64: vgic-v3: Clear pending bit in guest memory after synchronization Zenghui Yu
2020-03-31 3:12 ` Zenghui Yu
2020-03-31 3:12 ` Zenghui Yu
2020-03-31 8:07 ` Marc Zyngier [this message]
2020-03-31 8:07 ` Marc Zyngier
2020-03-31 8:07 ` Marc Zyngier
2020-03-31 9:11 ` Zenghui Yu
2020-03-31 9:11 ` Zenghui Yu
2020-03-31 9:11 ` Zenghui Yu
2020-04-01 10:27 ` Marc Zyngier
2020-04-01 10:27 ` Marc Zyngier
2020-04-01 10:27 ` Marc Zyngier
2020-04-01 12:52 ` Zenghui Yu
2020-04-01 12:52 ` Zenghui Yu
2020-04-01 12:52 ` Zenghui Yu
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=20200331090709.17d2087d@why \
--to=maz@kernel.org \
--cc=andre.przywara@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.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.