[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<PAWPR08MB89096DF4699C5F17F37B17499F872@PAWPR08MB8909.eurprd08.prod.outlook.com>
Date: Sat, 26 Apr 2025 12:49:42 +0000
From: Wathsala Wathawana Vithanage <wathsala.vithanage@....com>
To: Alex Williamson <alex.williamson@...hat.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, nd
<nd@....com>, Jason Gunthorpe <jgg@...pe.ca>, Kevin Tian
<kevin.tian@...el.com>, Philipp Stanner <pstanner@...hat.com>, Yunxiang Li
<Yunxiang.Li@....com>, "Dr. David Alan Gilbert" <linux@...blig.org>, Ankit
Agrawal <ankita@...dia.com>, "open list:VFIO DRIVER" <kvm@...r.kernel.org>,
Jeremy Linton <Jeremy.Linton@....com>, Honnappa Nagarahalli
<Honnappa.Nagarahalli@....com>, Dhruv Tripathi <Dhruv.Tripathi@....com>
Subject: RE: [RFC PATCH] vfio/pci: add PCIe TPH to device feature ioctl
> > For cases where steering-tag is not required in user-space (VMMs),
> > caller asks the kernel to set steering-tag that corresponds the
> > cpu-id, cache-level, and PH combination at a given MSI-X vector entry
> > or ST table in config space. For such cases too, the kernel will read
> > the steering-tag from the _DSM and set the tag in the corresponding MSI-X or
> ST table entry.
>
> We need to consider that there are vfio-pci variant drivers that support migration
> and make use of the vfio-pci-core feature interface.
> TPH programming appears to be very non-migration friendly, the attributes are
> very specific to the current host system. Should migration and TPH be mutually
> exclusive? This may be a factor in the decision to use a feature or ioctl.
>
TPH isn't migration friendly at least for the time being. Therefore, this should be
implemented as an ioctl.
--wathsala
Powered by blists - more mailing lists