On Tue, 20 Apr 2021 06:08:29 -0400
"Michael S. Tsirkin" wrote:
> On Tue, Apr 20, 2021 at 08:01:29AM +0100, Christoph Hellwig wrote:
> > Just to despit my 2 cents again: I think the way this is specified
> > in the virtio spec is actively harmful and we should not suport it in
> > Linux.
> >
>
rnel.org
> Signed-off-by: Christian A. Ehrhardt
> ---
> drivers/vfio/pci/vfio_pci.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Cornelia Huck
On Mon, 29 Mar 2021 17:10:53 -0600
Alex Williamson wrote:
> On Tue, 23 Mar 2021 16:32:13 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Mar 22, 2021 at 10:40:16AM -0600, Alex Williamson wrote:
> > > So unless you want to do some bitkeeper archaeology, we've always
> > > allowed driver probes to
On Thu, 4 Mar 2021 16:24:16 +0800
Jason Wang wrote:
> On 2021/3/3 4:29 下午, Cornelia Huck wrote:
> > On Wed, 3 Mar 2021 12:01:01 +0800
> > Jason Wang wrote:
> >
> >> On 2021/3/2 8:08 下午, Cornelia Huck wrote:
> >>> On Mon, 1 Mar 2
On Wed, 3 Mar 2021 12:01:01 +0800
Jason Wang wrote:
> On 2021/3/2 8:08 下午, Cornelia Huck wrote:
> > On Mon, 1 Mar 2021 11:51:08 +0800
> > Jason Wang wrote:
> >
> >> On 2021/3/1 5:25 上午, Michael S. Tsirkin wrote:
> >>> On Fri, Feb 26,
On Mon, 1 Mar 2021 11:51:08 +0800
Jason Wang wrote:
> On 2021/3/1 5:25 上午, Michael S. Tsirkin wrote:
> > On Fri, Feb 26, 2021 at 04:19:16PM +0800, Jason Wang wrote:
> >> On 2021/2/26 2:53 上午, Michael S. Tsirkin wrote:
> >>> Confused. What is wrong with the above? It never reads the
> >>>
On Thu, 25 Feb 2021 12:36:07 +0800
Jason Wang wrote:
> On 2021/2/24 7:12 下午, Cornelia Huck wrote:
> > On Wed, 24 Feb 2021 17:29:07 +0800
> > Jason Wang wrote:
> >
> >> On 2021/2/23 6:58 下午, Cornelia Huck wrote:
> >>> On Tue, 23 Feb 2
On Wed, 24 Feb 2021 17:29:07 +0800
Jason Wang wrote:
> On 2021/2/23 6:58 下午, Cornelia Huck wrote:
> > On Tue, 23 Feb 2021 18:31:07 +0800
> > Jason Wang wrote:
> >
> >> On 2021/2/23 6:04 下午, Cornelia Huck wrote:
> >>> On Tue, 23 Feb 2
On Tue, 23 Feb 2021 18:31:07 +0800
Jason Wang wrote:
> On 2021/2/23 6:04 下午, Cornelia Huck wrote:
> > On Tue, 23 Feb 2021 17:46:20 +0800
> > Jason Wang wrote:
> >
> >> On 2021/2/23 下午5:25, Michael S. Tsirkin wrote:
> >>> On Mon, Feb 22,
On Tue, 23 Feb 2021 17:46:20 +0800
Jason Wang wrote:
> On 2021/2/23 下午5:25, Michael S. Tsirkin wrote:
> > On Mon, Feb 22, 2021 at 09:09:28AM -0800, Si-Wei Liu wrote:
> >>
> >> On 2/21/2021 8:14 PM, Jason Wang wrote:
> >>> On 2021/2/19 7:54 下午, Si-Wei Liu wrote:
> Commit 452639a64ad8
ried to follow down
the various paths; and while I think it's ok, I do not really have
enough confidence about that for a R-b. But have an
Acked-by: Cornelia Huck
x VA->PA translation for PFNMAP VMAs in
> vaddr_get_pfn()")
> Signed-off-by: Alex Williamson
> ---
> drivers/vfio/vfio_iommu_type1.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
With the function signature adapted:
Reviewed-by: Cornelia Huck
On Thu, 11 Feb 2021 11:29:37 -0500
Matthew Rosato wrote:
> On 2/11/21 10:47 AM, Max Gurtovoy wrote:
> >
> > On 2/2/2021 7:10 PM, Jason Gunthorpe wrote:
> >> On Tue, Feb 02, 2021 at 05:06:59PM +0100, Cornelia Huck wrote:
> >>
> >>> On the oth
On Wed, 10 Feb 2021 15:34:24 -0500
Tony Krowiak wrote:
> On 2/10/21 5:53 AM, Cornelia Huck wrote:
> > On Tue, 9 Feb 2021 14:48:30 -0500
> > Tony Krowiak wrote:
> >
> >> This patch fixes a circular locking dependency in the CI introduced by
> >> commi
On Tue, 9 Feb 2021 14:48:30 -0500
Tony Krowiak wrote:
> This patch fixes a circular locking dependency in the CI introduced by
> commit f21916ec4826 ("s390/vfio-ap: clean up vfio_ap resources when KVM
> pointer invalidated"). The lockdep only occurs when starting a Secure
> Execution guest.
On Thu, 4 Feb 2021 16:05:23 +0800
Zheng Yongjun wrote:
> When valloc failed, should return ENOMEM rather than ENOBUF.
>
> Signed-off-by: Zheng Yongjun
> ---
> arch/s390/kvm/interrupt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/kvm/interrupt.c
On Mon, 1 Feb 2021 11:42:30 -0700
Alex Williamson wrote:
> On Mon, 1 Feb 2021 12:49:12 -0500
> Matthew Rosato wrote:
>
> > On 2/1/21 12:14 PM, Cornelia Huck wrote:
> > > On Mon, 1 Feb 2021 16:28:27 +
> > > Max Gurtovoy wrote:
> > >
On Mon, 1 Feb 2021 13:47:57 -0700
Alex Williamson wrote:
> On Mon, 1 Feb 2021 12:08:45 -0500
> Matthew Rosato wrote:
>
> > On 2/1/21 11:52 AM, Cornelia Huck wrote:
> > > On Mon, 1 Feb 2021 16:28:25 +
> > > Max Gurtovoy wrote:
> > >
>
insertions(+), 12 deletions(-)
Reviewed-by: Cornelia Huck
On Mon, 1 Feb 2021 16:28:27 +
Max Gurtovoy wrote:
> This patch doesn't change any logic but only align to the concept of
> vfio_pci_core extensions. Extensions that are related to a platform
> and not to a specific vendor of PCI devices should be part of the core
> driver. Extensions that
On Mon, 1 Feb 2021 16:28:25 +
Max Gurtovoy wrote:
> In case allocation fails, we must behave correctly and exit with error.
>
> Signed-off-by: Max Gurtovoy
Fixes: e6b817d4b821 ("vfio-pci/zdev: Add zPCI capabilities to
VFIO_DEVICE_GET_INFO")
Reviewed-by: Corn
On Tue, 26 Jan 2021 15:27:43 +0200
Max Gurtovoy wrote:
> Hi Alex, Cornelia and Jason,
>
> thanks for the reviewing this.
>
> On 1/26/2021 5:34 AM, Alex Williamson wrote:
> > On Mon, 25 Jan 2021 20:45:22 -0400
> > Jason Gunthorpe wrote:
> >
> >> On Mon, Jan 25, 2021 at 04:31:51PM -0700, Alex
On Wed, 27 Jan 2021 08:53:05 -0700
Alex Williamson wrote:
> On Wed, 27 Jan 2021 09:23:04 -0500
> Matthew Rosato wrote:
>
> > On 1/26/21 6:18 PM, Alex Williamson wrote:
> > > On Mon, 25 Jan 2021 09:40:38 -0500
> > > Matthew Rosato wrote:
> > >
> > >> On 1/22/21 6:48 PM, Alex Williamson
On Mon, 25 Jan 2021 09:40:38 -0500
Matthew Rosato wrote:
> On 1/22/21 6:48 PM, Alex Williamson wrote:
> > On Tue, 19 Jan 2021 15:02:30 -0500
> > Matthew Rosato wrote:
> >
> >> Some s390 PCI devices (e.g. ISM) perform I/O operations that have very
> >> specific requirements in terms of
On Fri, 22 Jan 2021 16:04:21 -0400
Jason Gunthorpe wrote:
> On Fri, Jan 22, 2021 at 12:25:03PM -0700, Alex Williamson wrote:
> > > In this way, we'll use the HW vendor driver core to manage the lifecycle
> > > of these devices. This is reasonable since only the vendor driver knows
> > > exactly
_ap_mdev_reset_queue(struct vfio_ap_queue *q,
> + unsigned int retry);
> +
> #endif /* _VFIO_AP_PRIVATE_H_ */
>
> base-commit: 9791581c049c10929e97098374dd1716a81fefcc
Anyway, if I didn't entangle myself in the various branches, this seems
sane.
Reviewed-by: Cornelia Huck
On Mon, 18 Jan 2021 14:16:26 -0400
Jason Gunthorpe wrote:
> On Mon, Jan 18, 2021 at 05:00:09PM +0100, Cornelia Huck wrote:
>
> > > You can say that all the HW specific things are in the mlx5_vfio_pci
> > > driver. It is an unusual driver because it must bind
ry. Trigger a segmentation fault.
> >> + */
>
> Sounds good
>
> >> + if (user_mode(regs)) {
> >> + send_sig(SIGSEGV, current, 0);
> >> + return;
> >> + } else
> >> + panic("Unexpected PGM 0x3d with TEID bit 61=0");
> >
> > use BUG instead of panic? That would kill this process, but it allows
> > people to maybe save unaffected data.
>
> That would make sense, will do
With BUG():
Reviewed-by: Cornelia Huck
pgpICNfGBeLQd.pgp
Description: OpenPGP digital signature
ixes: a0f60f8431999 ("s390/protvirt: Add sysfs firmware interface for
> Ultravisor information")
> Cc: sta...@vger.kernel.org
> ---
> arch/s390/boot/uv.c| 2 +-
> arch/s390/include/asm/uv.h | 4 ++--
> arch/s390/kernel/uv.c | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
Acked-by: Cornelia Huck
On Mon, 18 Jan 2021 11:10:20 -0400
Jason Gunthorpe wrote:
> On Mon, Jan 18, 2021 at 02:38:06PM +0100, Cornelia Huck wrote:
>
> > > These devices will be seen on the Auxiliary bus as:
> > > mlx5_core.vfio_pci.2048 ->
> > > ../../../devices/pci:00/:00
On Sun, 17 Jan 2021 18:15:31 +
Max Gurtovoy wrote:
> Hi Alex and Cornelia,
>
> This series split the vfio_pci driver into 2 parts: pci driver and a
> subsystem driver that will also be library of code. The pci driver,
> vfio_pci.ko will be used as before and it will bind to the subsystem
>
On Thu, 17 Dec 2020 11:04:48 -0500
Matthew Rosato wrote:
> On 12/17/20 7:59 AM, Cornelia Huck wrote:
> > The basic question I have is whether it makes sense to specialcase the
> > ISM device (can we even find out that we're dealing with an ISM device
> > here?) to force the
On Tue, 22 Dec 2020 10:37:01 -0500
Tony Krowiak wrote:
> On 12/21/20 11:05 PM, Halil Pasic wrote:
> > On Mon, 21 Dec 2020 13:56:25 -0500
> > Tony Krowiak wrote:
> >> static int vfio_ap_mdev_group_notifier(struct notifier_block *nb,
> >> unsigned long action,
On Fri, 11 Dec 2020 10:04:43 -0500
Matthew Rosato wrote:
> On 12/11/20 10:01 AM, Matthew Rosato wrote:
> > On 12/11/20 9:35 AM, Cornelia Huck wrote:
> >> Let me summarize this to make sure I understand this new region
> >> correctly:
> >>
> >> - s
f-by: Tony Krowiak
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 29 -
> 1 file changed, 20 insertions(+), 9 deletions(-)
Reviewed-by: Cornelia Huck
On Thu, 10 Dec 2020 10:51:23 -0500
Matthew Rosato wrote:
> On 12/10/20 7:33 AM, Cornelia Huck wrote:
> > On Wed, 9 Dec 2020 15:27:46 -0500
> > Matthew Rosato wrote:
> >
> >> Today, ISM devices are completely disallowed for vfio-pci passthrough as
> &
On Thu, 10 Dec 2020 17:14:24 +0100
Niklas Schnelle wrote:
> On 12/10/20 4:51 PM, Matthew Rosato wrote:
> > On 12/10/20 7:33 AM, Cornelia Huck wrote:
> >> On Wed, 9 Dec 2020 15:27:46 -0500
> >> Matthew Rosato wrote:
> >>
> >>> Today, IS
On Thu, 10 Dec 2020 10:26:22 -0500
Matthew Rosato wrote:
> On 12/10/20 5:33 AM, Cornelia Huck wrote:
> > On Wed, 9 Dec 2020 15:27:47 -0500
> > Matthew Rosato wrote:
> >
> >> Some zpci device types (e.g., ISM) follow different rules for length
> >
On Wed, 9 Dec 2020 15:27:46 -0500
Matthew Rosato wrote:
> Today, ISM devices are completely disallowed for vfio-pci passthrough as
> QEMU will reject the device due to an (inappropriate) MSI-X check.
> However, in an effort to enable ISM device passthrough, I realized that the
> manner in which
On Wed, 9 Dec 2020 15:27:47 -0500
Matthew Rosato wrote:
> Some zpci device types (e.g., ISM) follow different rules for length
> and alignment of pci instructions. Recognize this and keep track of
> it in the zpci_dev.
>
> Signed-off-by: Matthew Rosato
> Reviewed-by: Niklas Schnelle
>
educe the performance loss
> > caused by refactoring.
> >
> > Signed-off-by: Xiaoyang Xu
(...)
>
> hi Cornelia Huck, Eric Farman, Zhenyu Wang, Zhi Wang
>
> vfio_pin_pages() accepts an array of unrelated iova pfns and processes
> each to return the physical
On Fri, 4 Dec 2020 11:48:24 -0500
Tony Krowiak wrote:
> On 12/3/20 12:55 PM, Halil Pasic wrote:
> > On Wed, 2 Dec 2020 18:41:01 -0500
> > Tony Krowiak wrote:
> >
> >> The vfio_ap device driver registers a group notifier with VFIO when the
> >> file descriptor for a VFIO mediated device for a
On Tue, 27 Oct 2020 19:58:03 +0200
Andy Shevchenko wrote:
> Switch to use new platform_get_mem_or_io_resource() instead of
> home grown analogue.
>
> Cc: Eric Auger
> Cc: Alex Williamson
> Cc: Cornelia Huck
> Cc: k...@vger.kernel.org
> Signed-off-by: Andy Shevchenk
chenko
> Cc: Eric Auger
> Cc: Alex Williamson
> Cc: Cornelia Huck
> Cc: k...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Peng Hao
> Cc: Arnd Bergmann
> ---
> include/linux/platform_device.h | 13 +
> 1 file changed, 13 insertions(+)
>
>
On Wed, 2 Dec 2020 18:41:01 -0500
Tony Krowiak wrote:
> The vfio_ap device driver registers a group notifier with VFIO when the
> file descriptor for a VFIO mediated device for a KVM guest is opened to
> receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM
> event). When
io: add basic protected virtualization support")
> Reported-by: Hulk Robot
> Suggested-by: Cornelia Huck
> Signed-off-by: Qinglang Miao
> ---
> This patch is indeed a v2 of older one. Considering that the
> patch's name has changed, I think a normal prefix 'PATCH' is
On Thu, 26 Nov 2020 09:27:41 +0800
Qinglang Miao wrote:
> 在 2020/11/26 1:06, Benjamin Block 写道:
> > On Fri, Nov 20, 2020 at 03:48:54PM +0800, Qinglang Miao wrote:
> >> kfree(port) is called in put_device(>dev) so that following
> >> use would cause use-after-free bug.
> >>
> >> The former
On Sat, 14 Nov 2020 00:47:22 +0100
Halil Pasic wrote:
> On Fri, 13 Nov 2020 12:14:22 -0500
> Tony Krowiak wrote:
> [..]
> > >> }
> > >>
> > >> +#define MDEV_SHARING_ERR "Userspace may not re-assign queue %02lx.%04lx
> > >> " \
> > >> + "already assigned to %s"
> >
On Fri, 20 Nov 2020 15:48:50 +0800
Qinglang Miao wrote:
> kfree(cdev) is called in put_device in the error branch. So that
> device_unlock(>dev) would raise a use-after-free bug. In fact,
> there's no need to call device_unlock after put_device.
>
> Fix it by adding simply return after
On Fri, 20 Nov 2020 15:48:49 +0800
Qinglang Miao wrote:
> put_device calls release function which do kfree() inside.
> So following use of sch would cause use-after-free bugs.
>
> Fix these by simply adjusting the position of put_device.
>
> Fixes: 37db8985b211 ("s390/cio: add basic protected
| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Cornelia Huck
| 37 ++
> drivers/vfio/pci/vfio_pci_private.h | 12 +++
> drivers/vfio/pci/vfio_pci_zdev.c| 143
>
> 5 files changed, 206 insertions(+)
> create mode 100644 drivers/vfio/pci/vfio_pci_zdev.c
With the compilation fix,
Reviewed-by: Cornelia Huck
zPCI devices.
>
> Signed-off-by: Matthew Rosato
> ---
> include/uapi/linux/vfio.h | 11 ++
> include/uapi/linux/vfio_zdev.h | 78
> ++
> 2 files changed, 89 insertions(+)
> create mode 100644 include/uapi/linux/vfio_zdev.h
Reviewed-by: Cornelia Huck
inux-s...@vger.kernel.org
> +L: k...@vger.kernel.org
> +S: Supported
> +F: drivers/vfio/pci/vfio_pci_zdev.c
> +F: include/uapi/linux/vfio_zdev.h
> +
> S390 ZCRYPT DRIVER
> M: Harald Freudenberger
> L: linux-s...@vger.kernel.org
Acked-by: Cornelia Huck
cked-by: Christian Borntraeger
> ---
> arch/s390/include/asm/pci.h | 3 ++-
> arch/s390/pci/pci_clp.c | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
FWIW:
Acked-by: Cornelia Huck
On Mon, 5 Oct 2020 12:16:10 -0400
Matthew Rosato wrote:
> On 10/5/20 12:01 PM, Cornelia Huck wrote:
> > On Mon, 5 Oct 2020 09:52:25 -0400
> > Matthew Rosato wrote:
> >
> >> On 10/2/20 5:44 PM, Alex Williamson wrote:
> >
> >>> Can you dis
On Mon, 5 Oct 2020 09:52:25 -0400
Matthew Rosato wrote:
> On 10/2/20 5:44 PM, Alex Williamson wrote:
> > Can you discuss why a region with embedded capability chain is a better
> > solution than extending the VFIO_DEVICE_GET_INFO ioctl to support a
> > capability chain and providing this info
On Wed, 23 Sep 2020 15:45:27 -0700
Sean Christopherson wrote:
> This series introduces a concept we've discussed a few times in x86 land.
> The crux of the problem is that x86 has a few cases where KVM could
> theoretically encounter a software or hardware bug deep in a call stack
> without any
On Sat, 19 Sep 2020 11:28:38 -0400
Matthew Rosato wrote:
> Define a new configuration entry VFIO_PCI_ZDEV for VFIO/PCI.
>
> When this s390-only feature is configured we initialize a new device
> region, VFIO_REGION_SUBTYPE_IBM_ZPCI_CLP, to hold information provided
> by the underlying hardware.
On Sat, 19 Sep 2020 11:28:37 -0400
Matthew Rosato wrote:
> We define a new device region in vfio.h to be able to get the ZPCI CLP
> information by reading this region from userspace.
>
> We create a new file, vfio_zdev.h to define the structure of the new
> region defined in vfio.h
>
>
On Mon, 21 Sep 2020 11:44:20 -0400
Matthew Rosato wrote:
> On 9/21/20 11:01 AM, Cornelia Huck wrote:
> > On Sat, 19 Sep 2020 11:28:35 -0400
> > Matthew Rosato wrote:
> >
> >> In preparation for passing the info on to vfio-pci devices, stash the
> >&g
On Sat, 19 Sep 2020 11:28:35 -0400
Matthew Rosato wrote:
> In preparation for passing the info on to vfio-pci devices, stash the
> supported PCI version for the target device in the zpci_dev.
Hm, what kind of version is that? The version of the zPCI interface?
Inquiring minds want to know :)
ar = (__le32 *)>vconfig[PCI_BASE_ADDRESS_0];
>
> for (i = 0; i < PCI_STD_NUM_BARS; i++, vbar++) {
Reviewed-by: Cornelia Huck
On Fri, 18 Sep 2020 13:02:34 -0400
Tony Krowiak wrote:
> Attempting to unregister Guest Interruption Subclass (GISC) when the
> link between the matrix mdev and KVM has been removed results in the
> following:
>
>"Kernel panic -not syncing: Fatal exception: panic_on_oops"
I'm wondering how
On Fri, 21 Aug 2020 15:56:07 -0400
Tony Krowiak wrote:
> The matrix of adapters and domains configured in a guest's CRYCB may
> differ from the matrix of adapters and domains assigned to the matrix mdev,
> so this patch introduces a sysfs attribute to display the matrix of a guest
> using the
On Fri, 21 Aug 2020 15:56:06 -0400
Tony Krowiak wrote:
> The APCB is a field within the CRYCB that provides the AP configuration
> to a KVM guest. Let's introduce a shadow copy of the KVM guest's APCB and
> maintain it for the lifespan of the guest.
>
> Signed-off-by: Tony Krowiak
> ---
>
On Tue, 15 Sep 2020 15:32:35 -0400
Tony Krowiak wrote:
> On 9/14/20 11:29 AM, Cornelia Huck wrote:
> > On Fri, 21 Aug 2020 15:56:04 -0400
> > Tony Krowiak wrote:
> >
> >> Introduces a new driver callback to prevent a root user from unbinding
> >
; 2 files changed, 8 deletions(-)
Yes, it seems to have been write-only all the time.
Reviewed-by: Cornelia Huck
{
>
> static int vfio_pci_reflck_attach(struct vfio_pci_device *vdev);
> static void vfio_pci_reflck_put(struct vfio_pci_reflck *reflck);
> -static struct pci_driver vfio_pci_driver;
>
> static int vfio_pci_bus_notifier(struct notifier_block *nb,
> unsigned long action, void *data)
Reviewed-by: Cornelia Huck
> include/uapi/linux/vfio.h | 15 +++
> 2 files changed, 32 insertions(+)
Reviewed-by: Cornelia Huck
On Mon, 14 Sep 2020 18:25:31 -0400
Matthew Rosato wrote:
> Commit 492855939bdb ("vfio/type1: Limit DMA mappings per container")
> added the ability to limit the number of memory backed DMA mappings.
> However on s390x, when lazy mapping is in use, we use a very large
> number of concurrent
44104 ("vfio: Selective dirty page tracking if IOMMU backed
device pins pages")
>
> Signed-off-by: Yan Zhao
> ---
> drivers/vfio/vfio.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Cornelia Huck
On Fri, 21 Aug 2020 15:56:05 -0400
Tony Krowiak wrote:
> Let's implement the callback to indicate when an APQN
> is in use by the vfio_ap device driver. The callback is
> invoked whenever a change to the apmask or aqmask would
> result in one or more queue devices being removed from the driver.
On Fri, 21 Aug 2020 15:56:04 -0400
Tony Krowiak wrote:
> Introduces a new driver callback to prevent a root user from unbinding
> an AP queue from its device driver if the queue is in use. The intent of
> this callback is to provide a driver with the means to prevent a root user
> from
ication
> may
> *optionally change the VFIO device state from _RUNNING to _STOP. This
> *transition is optional. The vendor driver must support this transition
> but
Reviewed-by: Cornelia Huck
On Tue, 1 Sep 2020 16:50:03 +0800
Jason Wang wrote:
> On 2020/9/1 下午1:24, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On 28/08/20 4:04 pm, Cornelia Huck wrote:
> >> On Thu, 9 Jul 2020 14:26:53 +0800
> >> Jason Wang wrote:
> >>
> >&g
On Tue, 8 Sep 2020 00:39:51 +0200
Halil Pasic wrote:
> On Mon, 7 Sep 2020 11:39:05 +0200
> Pierre Morel wrote:
>
> > Hi all,
> >
> > The goal of the series is to give a chance to the architecture
> > to validate VIRTIO device features.
>
> Michael, is this going in via your tree?
>
I
On Thu, 9 Jul 2020 14:26:53 +0800
Jason Wang wrote:
[Let me note right at the beginning that I first noted this while
listening to Kishon's talk at LPC on Wednesday. I might be very
confused about the background here, so let me apologize beforehand for
any confusion I might spread.]
> On
On Thu, 27 Aug 2020 10:24:07 -0400
Tony Krowiak wrote:
> On 8/25/20 6:13 AM, Cornelia Huck wrote:
> > On Fri, 21 Aug 2020 15:56:02 -0400
> > Tony Krowiak wrote:
> >> /**
> >> - * vfio_ap_get_queue: Retrieve a queue with a specific APQN from a list
>
On Thu, 27 Aug 2020 10:39:07 -0400
Tony Krowiak wrote:
> Currently there are two tools that probably need to be aware of
> the changes to these assignment interfaces:
> * The hades test framework has tests that will fail if run against
> these patches that should be skipped if
On Wed, 26 Aug 2020 10:49:47 -0400
Tony Krowiak wrote:
> On 8/25/20 6:04 AM, Cornelia Huck wrote:
> > On Fri, 21 Aug 2020 15:56:01 -0400
> > Tony Krowiak wrote:
> >
> >> Let's set a version for the vfio_ap module so that automated regression
> >&
On Fri, 21 Aug 2020 15:56:16 -0400
Tony Krowiak wrote:
> Update the documentation in vfio-ap.rst to include information about the
> AP dynamic configuration support (i.e., hot plug of adapters, domains
> and control domains via the matrix mediated device's sysfs assignment
> attributes).
>
>
On Fri, 21 Aug 2020 15:56:03 -0400
Tony Krowiak wrote:
> Let's create links between each queue device bound to the vfio_ap device
> driver and the matrix mdev to which the queue is assigned. The idea is to
> facilitate efficient retrieval of the objects representing the queue
> devices and
On Fri, 21 Aug 2020 15:56:02 -0400
Tony Krowiak wrote:
> This patch refactor's the vfio_ap device driver to use the AP bus's
s/refactor's/refactors/
> ap_get_qdev() function to retrieve the vfio_ap_queue struct containing
> information about a queue that is bound to the vfio_ap device driver.
On Fri, 21 Aug 2020 15:56:01 -0400
Tony Krowiak wrote:
> Let's set a version for the vfio_ap module so that automated regression
> tests can determine whether dynamic configuration tests can be run or
> not.
>
> Signed-off-by: Tony Krowiak
> ---
> drivers/s390/crypto/vfio_ap_drv.c | 2 ++
> 1
pgd_t swapper_pg_dir[PTRS_PER_PGD] __section(.bss..swapper_pg_dir);
>
(...)
With the nit fixed,
Reviewed-by: Cornelia Huck
the architecture may need to enforce
VIRTIO_F_IOMMU_PLATFORM."
?
> +
> menuconfig VIRTIO_MENU
> bool "Virtio drivers"
> default y
(...)
Reviewed-by: Cornelia Huck
On Wed, 19 Aug 2020 10:50:18 +0200
Pierre Morel wrote:
> On 2020-08-18 19:19, Cornelia Huck wrote:
> > On Tue, 18 Aug 2020 16:58:30 +0200
> > Pierre Morel wrote:
> >
> ...
> >> +config ARCH_HAS_RESTRICTED_MEMORY_ACCESS
> >> + bool
> >&g
On Tue, 18 Aug 2020 16:58:31 +0200
Pierre Morel wrote:
> If protected virtualization is active on s390, the virtio queues are
> not accessible to the host, unless VIRTIO_F_IOMMU_PLATFORM has been
> negotiated.
> Define CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS and export
>
On Tue, 18 Aug 2020 16:58:30 +0200
Pierre Morel wrote:
> An architecture may need to validate the VIRTIO devices features
> based on architecture specifics.
>
> Provide a new Kconfig entry, CONFIG_ARCH_HAS_RESTRICTED_MEMORY_ACCESS,
> the architecture can select when it provides a callback named
disposition of each entry.
>
> Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices")
> Signed-off-by: Alex Williamson
> ---
> drivers/vfio/vfio_iommu_type1.c | 71
> ++++---
> 1 file changed, 66 insertions(+), 5 deletions(-)
Reviewed-by: Cornelia Huck
On Thu, 6 Aug 2020 16:23:01 +0200
Pierre Morel wrote:
> Hi all,
>
> In another series I proposed to add an architecture specific
> callback to fail feature negociation on architecture need.
>
> In VIRTIO, we already have an entry to reject the features on the
> transport basis.
>
> Transport
++---
> 2 files changed, 98 insertions(+), 24 deletions(-)
Reviewed-by: Cornelia Huck
On Wed, 5 Aug 2020 09:45:00 -0400
"Michael S. Tsirkin" wrote:
> Speed and duplex config fields depend on VIRTIO_NET_F_SPEED_DUPLEX
> which being 63>31 depends on VIRTIO_F_VERSION_1.
>
> Accordingly, use LE accessors for these fields.
>
> Reported-by: Cornelia H
> No functional changes.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/platform/mellanox/mlxbf-tmfifo.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
Acked-by: Cornelia Huck
On Mon, 3 Aug 2020 16:59:57 -0400
"Michael S. Tsirkin" wrote:
> Transitional devices should all use __virtioXX types.
I think they should use __leXX for those fields that are not present
with legacy devices?
> Modern ones should use __leXX.
> _uXX type would be a bug.
> Let's prevent that.
-
> 2 files changed, 12 insertions(+), 12 deletions(-)
Reviewed-by: Cornelia Huck
d, 2 insertions(+), 2 deletions(-)
Reviewed-by: Cornelia Huck
On Mon, 3 Aug 2020 16:59:37 -0400
"Michael S. Tsirkin" wrote:
> Tag config space fields as having virtio endian-ness.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> include/uapi/linux/virtio_net.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git
t;
> Signed-off-by: Michael S. Tsirkin
> ---
> include/uapi/linux/virtio_mem.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
Reviewed-by: Cornelia Huck
1 - 100 of 2319 matches
Mail list logo
