From: Alex Williamson <alex.williamson@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "Tian\, Kevin" <kevin.tian@intel.com>,
Jason Gunthorpe <jgg@nvidia.com>, "Dey\,
Megha" <megha.dey@intel.com>, "Raj\, Ashok" <ashok.raj@intel.com>,
"Pan\, Jacob jun" <jacob.jun.pan@intel.com>, "Jiang\,
Dave" <dave.jiang@intel.com>, "Liu\, Yi L" <yi.l.liu@intel.com>,
"Lu\, Baolu" <baolu.lu@intel.com>, "Williams\,
Dan J" <dan.j.williams@intel.com>, "Luck\,
Tony" <tony.luck@intel.com>, "Kumar\,
Sanjay K" <sanjay.k.kumar@intel.com>,
LKML <linux-kernel@vger.kernel.org>, KVM <kvm@vger.kernel.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
Peter Zijlstra <peterz@infradead.org>,
Marc Zyngier <maz@kernel.org>, Bjorn Helgaas <helgaas@kernel.org>
Subject: Re: Virtualizing MSI-X on IMS via VFIO
Date: Thu, 24 Jun 2021 15:44:34 -0600 [thread overview]
Message-ID: <20210624154434.11809b8f.alex.williamson@redhat.com> (raw)
In-Reply-To: <8735t7wazk.ffs@nanos.tec.linutronix.de>
On Thu, 24 Jun 2021 17:14:39 +0200
Thomas Gleixner <tglx@linutronix.de> wrote:
> After studying the MSI-X specification again, I think there is another
> option to solve this for MSI-X, i.e. the dynamic sizing part:
>
> MSI requires to disable MSI in order to update the number of enabled
> vectors in the control word.
Exactly what part of the spec requires this? This is generally the
convention I expect too, and there are complications around contiguous
vectors and data field alignment, but I'm not actually able to find a
requirement in the spec that MSI Enable must be 0 when modifying other
writable fields or that writable fields are latched when MSI Enable is
set.
> MSI-X does not have that requirement as there is no 'number of used
> vectors' control field. MSI-X provides a fixed sized vector table and
> enabling MSI-X "activates" the full table.
>
> System software has to set proper messages in the table and eventually
> associate the table entries to device (sub)functions if that's not
> hardwired in the device and controlled by queue enablement etc.
>
> According to the specification there is no requirement for masked table
> entries to contain a valid message:
>
> "Mask Bit: ... When this bit is set, the function is prohibited from
> sending a message using this MSI-X Table entry."
>
> which means that the function must reread the table entry when the mask
> bit in the vector control word is cleared.
What is a "valid" message as far as the device is concerned? "Valid"
is meaningful to system software and hardware, the device doesn't care.
Like MSI above, I think the real question is when is the data latched
by the hardware. For MSI-X this seems to be addressed in (PCIe 5.0
spec) 6.1.4.2 MSI-X Configuration:
Software must not modify the Address, Data, or Steering Tag fields of
an entry while it is unmasked.
Followed by 6.1.4.5 Per-vector Masking and Function Masking:
For MSI-X, a Function is permitted to cache Address and Data values
from unmasked MSI-X Table entries. However, anytime software unmasks
a currently masked MSI-X Table entry either by Clearing its Mask bit
or by Clearing the Function Mask bit, the Function must update any
Address or Data values that it cached from that entry. If software
changes the Address or Data value of an entry while the entry is
unmasked, the result is undefined.
So caching/latching occurs on unmask for MSI-X, but I can't find
similar statements for MSI. If you have, please note them. It's
possible MSI is per interrupt.
Anyway, at least MSI-X if not also MSI could have a !NORESIZE
implementation, which is why this flag exists in vfio. Thanks,
Alex
next prev parent reply other threads:[~2021-06-24 21:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 10:16 Virtualizing MSI-X on IMS via VFIO Tian, Kevin
2021-06-22 15:50 ` Dave Jiang
2021-06-23 6:16 ` Tian, Kevin
2021-06-22 19:12 ` Alex Williamson
2021-06-22 23:59 ` Thomas Gleixner
2021-06-23 6:12 ` Tian, Kevin
2021-06-23 16:31 ` Thomas Gleixner
2021-06-23 16:41 ` Jason Gunthorpe
2021-06-23 23:41 ` Tian, Kevin
2021-06-23 23:37 ` Tian, Kevin
2021-06-24 1:18 ` Thomas Gleixner
2021-06-24 2:41 ` Tian, Kevin
2021-06-24 15:14 ` Thomas Gleixner
2021-06-24 21:44 ` Alex Williamson [this message]
2021-06-25 5:21 ` Tian, Kevin
2021-06-25 8:43 ` Thomas Gleixner
2021-06-25 12:42 ` Thomas Gleixner
2021-06-25 21:19 ` Thomas Gleixner
2021-06-25 8:29 ` Thomas Gleixner
2021-06-24 17:03 ` Jacob Pan
2021-06-23 15:19 ` Alex Williamson
2021-06-24 0:00 ` Tian, Kevin
2021-06-24 1:36 ` Thomas Gleixner
2021-06-24 2:20 ` Thomas Gleixner
2021-06-24 2:48 ` Alex Williamson
2021-06-24 12:06 ` [PATCH] vfio/pci: Document the MSI[X] resize side effects properly Thomas Gleixner
2021-06-24 22:22 ` Alex Williamson
2021-06-24 17:52 ` Virtualizing MSI-X on IMS via VFIO Alex Williamson
2021-06-24 0:43 ` Thomas Gleixner
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=20210624154434.11809b8f.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=helgaas@kernel.org \
--cc=jacob.jun.pan@intel.com \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=megha.dey@intel.com \
--cc=peterz@infradead.org \
--cc=sanjay.k.kumar@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=yi.l.liu@intel.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