On Wed, Jun 21, 2023 at 08:04:22PM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin <m...@redhat.com> > > Sent: Wednesday, June 21, 2023 3:43 PM > > > > On Wed, Jun 21, 2023 at 04:01:00PM +0000, Parav Pandit wrote: > > > > > > > > > > From: Michael S. Tsirkin <m...@redhat.com> > > > > Sent: Wednesday, June 21, 2023 11:56 AM > > > > > > > Not like v3 please. If you want to re-open this: > > > > > > > > > > > > First I think we need multiple offsets just like notification > > > > capaiblity, sorted by priority. Second I think we need ability to > > > > report offset within owner not member. > > > > > > > > So please add ability to report multiple offsets, and add e.g. > > > > a flags field, with bits for owner, member. > > > > > > What are these multiple offsets for? > > > > Different BARs. For example, IO versus memory. Yes I know VFs don't support > > IO but PFs do. prefetch vs non-prefetch might matter too (non-prefetch is > > mostly limited to 32 bit). > > > BAR type and its prefetch attributes are told by the PCI anyway so no > duplication here anyway.
yes they are! But for example, software PF device might prefer notification in IO BAR if that can be mapped. If not - use MMIO. > For owner and member I get it. > > > > > Do you mean two offsets? One for owner and one for member? > > > Both bits are optional. Do you agree? > > > > I agree that everything should be optional sure. Let's not limit it to two > > though. > > There could be multiple BARs or whatever. We have ability to pass buffers of > > arbitrary length and device reports the length. > > Maybe have a SHOULD recommending not more than 10 of these (1 for each > > possible PCI BAR one for each possible VF BAR). > > > > This is to match the functionality that notification capability has. > > > A device can expose multiple offsets within the single bar to a count of 100 > entries; > Also allowed in the notification capability. > (I don't see why any sane device would do that anyway) Me neither. > So I will avoid such extra restrictions and limit the scope of this patch to > be minimal to have arbitrary number of BAR entries limited by the command > result length. That sounds OK. > > > > > > > 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-subscr...@lists.oasis-open.org > > > Unsubscribe: virtio-comment-unsubscr...@lists.oasis-open.org > > > List help: virtio-comment-h...@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/ --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
