From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: virtio-comment@lists.oasis-open.org, eric.auger@redhat.com,
virtio-dev@lists.oasis-open.org,
Zide Chen <zide.chen@intel.corp-partner.google.com>,
crosvm-dev@chromium.org
Subject: [virtio-comment] Re: [PATCH 4/4] virtio-iommu: Clarify hot-unplug behavior
Date: Mon, 14 Aug 2023 12:25:02 +0100 [thread overview]
Message-ID: <20230814112502.GA37241@myrica> (raw)
In-Reply-To: <b7b62822-4371-4a47-bc28-25a0b0ef92c5@daynix.com>
On Sat, Aug 12, 2023 at 03:25:10PM +0900, Akihiko Odaki wrote:
> > > By the way, crosvm's logic to detach endpoint on removal looks incorrect for
> > > me. A domain may have several endpoints attached, but the code looks like
> > > it's always destroying a domain whether there are other endpoints attached
> > > to the domain. I'm adding Zide Chen, who wrote the code according to git
> > > blame, and crosvm-dev@chromium.org to CC.
> >
> > Link to this thread for more context:
> > https://lore.kernel.org/virtio-dev/20230803153238.541803-5-jean-philippe@linaro.org/
> >
> > I thought crosvm rejected attaching multiple endpoints to one domain but I
> > think I misread. Rejecting multiple attach would be a straightforward fix
> > (it's allowed by the spec), though it would prevent assigning endpoints
> > that cannot be isolated from each others by the hardware (the driver won't
> > attach those to different domains, if it's made aware that they should be
> > in the same IOMMU group, for example if they are on a conventional PCI
> > bus).
>
> Now we figured out an endpoint should not be detached from a domain without
> a request from the driver anyway so the code to detach an endpoint can be
> simply removed.
Yes, but I think the other detach path, when handling ATTACH or DETACH
requests, doesn't support domains with multiple endpoints attached either:
// Currently, we only support detaching an endpoint if it is the only endpoint attached
// to its domain.
But the ATTACH handler seems to accept attaching multiple endpoints to the
same domain?
Thanks,
Jean
This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: virtio-comment@lists.oasis-open.org, eric.auger@redhat.com,
virtio-dev@lists.oasis-open.org,
Zide Chen <zide.chen@intel.corp-partner.google.com>,
crosvm-dev@chromium.org
Subject: [virtio-dev] Re: [PATCH 4/4] virtio-iommu: Clarify hot-unplug behavior
Date: Mon, 14 Aug 2023 12:25:02 +0100 [thread overview]
Message-ID: <20230814112502.GA37241@myrica> (raw)
In-Reply-To: <b7b62822-4371-4a47-bc28-25a0b0ef92c5@daynix.com>
On Sat, Aug 12, 2023 at 03:25:10PM +0900, Akihiko Odaki wrote:
> > > By the way, crosvm's logic to detach endpoint on removal looks incorrect for
> > > me. A domain may have several endpoints attached, but the code looks like
> > > it's always destroying a domain whether there are other endpoints attached
> > > to the domain. I'm adding Zide Chen, who wrote the code according to git
> > > blame, and crosvm-dev@chromium.org to CC.
> >
> > Link to this thread for more context:
> > https://lore.kernel.org/virtio-dev/20230803153238.541803-5-jean-philippe@linaro.org/
> >
> > I thought crosvm rejected attaching multiple endpoints to one domain but I
> > think I misread. Rejecting multiple attach would be a straightforward fix
> > (it's allowed by the spec), though it would prevent assigning endpoints
> > that cannot be isolated from each others by the hardware (the driver won't
> > attach those to different domains, if it's made aware that they should be
> > in the same IOMMU group, for example if they are on a conventional PCI
> > bus).
>
> Now we figured out an endpoint should not be detached from a domain without
> a request from the driver anyway so the code to detach an endpoint can be
> simply removed.
Yes, but I think the other detach path, when handling ATTACH or DETACH
requests, doesn't support domains with multiple endpoints attached either:
// Currently, we only support detaching an endpoint if it is the only endpoint attached
// to its domain.
But the ATTACH handler seems to accept attaching multiple endpoints to the
same domain?
Thanks,
Jean
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2023-08-14 11:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-03 15:32 [virtio-dev] [PATCH 0/4] virtio-iommu: Minor specification fixes Jean-Philippe Brucker
2023-08-03 15:32 ` [virtio-dev] [PATCH 1/4] virtio-iommu: Fix typo in label Jean-Philippe Brucker
2023-08-03 15:32 ` [virtio-dev] [PATCH 2/4] virtio-iommu: Fix RESV_MEM typo Jean-Philippe Brucker
2023-08-03 15:32 ` [virtio-dev] [PATCH 3/4] virtio-iommu: Fix contradictory and unnecessary statements Jean-Philippe Brucker
2023-08-03 15:32 ` [virtio-dev] [PATCH 4/4] virtio-iommu: Clarify hot-unplug behavior Jean-Philippe Brucker
2023-08-04 6:19 ` [virtio-dev] " Akihiko Odaki
2023-08-10 15:10 ` [virtio-comment] " Jean-Philippe Brucker
2023-08-10 15:10 ` [virtio-dev] " Jean-Philippe Brucker
2023-08-10 22:21 ` Akihiko Odaki
2023-08-11 14:20 ` [virtio-comment] " Jean-Philippe Brucker
2023-08-11 14:20 ` [virtio-dev] " Jean-Philippe Brucker
2023-08-12 6:25 ` Akihiko Odaki
2023-08-14 11:25 ` Jean-Philippe Brucker [this message]
2023-08-14 11:25 ` Jean-Philippe Brucker
2023-08-31 8:30 ` Akihiko Odaki
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=20230814112502.GA37241@myrica \
--to=jean-philippe@linaro.org \
--cc=akihiko.odaki@daynix.com \
--cc=crosvm-dev@chromium.org \
--cc=eric.auger@redhat.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio-dev@lists.oasis-open.org \
--cc=zide.chen@intel.corp-partner.google.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.