kvmarm.lists.cs.columbia.edu archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Zenghui Yu <yuzenghui@huawei.com>
Cc: kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
	eric.auger.pro@gmail.com
Subject: Re: [PATCH] KVM: arm/arm64: vgic-its: Fix restoration of unmapped collections
Date: Fri, 13 Dec 2019 11:28:43 +0000	[thread overview]
Message-ID: <9e9e3ed65ddf40ab72528187089e0997@www.loen.fr> (raw)
In-Reply-To: <d36b75e7-bd83-e501-3bd4-76bf0489c5ce@huawei.com>

Hi Zenghui,

On 2019-12-13 10:53, Zenghui Yu wrote:
> Hi Eric,
>
> On 2019/12/13 17:42, Eric Auger wrote:
>> Saving/restoring an unmapped collection is a valid scenario. For
>> example this happens if a MAPTI command was sent, featuring an
>> unmapped collection. At the moment the CTE fails to be restored.
>> Only compare against the number of online vcpus if the rdist
>> base is set.
>
> Have you actually seen a problem and this patch fixed it? To be 
> honest,
> I'm surprised to find that we can map a LPI to an unmapped collection 
> ;)
> (and prevent it to be delivered to vcpu with an 
> INT_UNMAPPED_INTERRUPT
> error, until someone had actually mapped the collection).
> After a quick glance of spec (MAPTI), just as you said, this is 
> valid.

Yes, this is one of the (many) odd bits in the architecture. And there 
is
a bizarre wording in the MAPC description when V=0:

"Behavior is unpredictable if there are interrupts that are mapped to 
the
specified collection, with the restriction that further translation 
requests
from that device are ignored."

It is really odd that:

- it is unpredictable to unmap the collection with mapped interrupts,
   but mapping interrupts to an unmapped collection is fine

- the notion of "interrupts from that device" doesn't match any of the
   MAPC parameters

Do you hate the GIC already? ;-)

> If Marc has no objection to this fix, please add
>
> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>

Thanks for that, I've applied it to the patch and will push out
the update as soon as ra.kernel.org is reachable again.

         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

  parent reply	other threads:[~2019-12-13 21:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13  9:42 [PATCH] KVM: arm/arm64: vgic-its: Fix restoration of unmapped collections Eric Auger
2019-12-13 10:43 ` Marc Zyngier
2019-12-13 10:55   ` Auger Eric
2019-12-13 10:53 ` Zenghui Yu
2019-12-13 11:06   ` Auger Eric
2019-12-13 11:28   ` Marc Zyngier [this message]
2019-12-13 14:22     ` 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=9e9e3ed65ddf40ab72528187089e0997@www.loen.fr \
    --to=maz@kernel.org \
    --cc=eric.auger.pro@gmail.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).