On Tue, 15 Jun 2021 15:35:09 +0200
Christoph Hellwig wrote:
> This is my alternative take on this series from Jason:
>
> https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
>
> The mdev/vfio parts are exactly the same, but this solves the driver core
> changes for the direct probing
On Tue, 15 Jun 2021 15:35:13 +0200
Christoph Hellwig wrote:
> @@ -547,10 +538,9 @@ static int call_driver_probe(struct device *dev, struct
> device_driver *drv)
>
> static int really_probe(struct device *dev, struct device_driver *drv)
> {
> - int local_trigger_count = atomic_read(&defer
On Tue, 20 Jul 2021 14:42:48 -0300
Jason Gunthorpe wrote:
> Compared to mbochs_remove() two cases are missing from the
> vfio_register_group_dev() unwind. Add them in.
>
> Fixes: 681c1615f891 ("vfio/mbochs: Convert to use vfio_register_group_dev()")
> Reported-by: Cornelia Huck
> Signed-off-by:
On Tue, 20 Jul 2021 19:49:55 -0300
Jason Gunthorpe wrote:
> On Tue, Jul 20, 2021 at 04:01:27PM -0600, Alex Williamson wrote:
> > On Tue, 20 Jul 2021 14:42:48 -0300
> > Jason Gunthorpe wrote:
> >
> > > Compared to mbochs_remove() two cases are missing from the
On Wed, 28 Jul 2021 21:49:18 -0300
Jason Gunthorpe wrote:
> Keep track of all the vfio_devices that have been added to the device set
> and use this list in vfio_pci_try_bus_reset() instead of trying to work
> backwards from the pci_device.
>
> The dev_set->lock directly prevents devices from jo
On Tue, 3 Aug 2021 13:41:52 -0300
Jason Gunthorpe wrote:
> On Tue, Aug 03, 2021 at 10:34:06AM -0600, Alex Williamson wrote:
> > I think the vfio_pci_find_reset_target() function needs to be re-worked
> > to just tell us true/false that it's ok to reset the provided device,
On Thu, 5 Aug 2021 08:47:01 -0300
Jason Gunthorpe wrote:
> On Tue, Aug 03, 2021 at 10:52:25AM -0600, Alex Williamson wrote:
> > On Tue, 3 Aug 2021 13:41:52 -0300
> > Jason Gunthorpe wrote:
> > > On Tue, Aug 03, 2021 at 10:34:06AM -0600, Alex Williamson wrot
On Thu, 5 Aug 2021 22:18:56 -0300
Jason Gunthorpe wrote:
> This is in support of Max's series to split vfio-pci. For that to work the
> reflck concept embedded in vfio-pci needs to be sharable across all of the
> new VFIO PCI drivers which motivated re-examining how this is
> implemented.
>
> A
On Fri, 10 Sep 2021 10:38:50 -0300
Jason Gunthorpe wrote:
> On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote:
> > On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:
> > > Every driver just emits a static string, simply feed it through the ops
> > > and provide a s
On Tue, 22 Jun 2021 21:05:50 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 17, 2021 at 04:22:08PM +0200, Christoph Hellwig wrote:
> > This is my alternative take on this series from Jason:
> >
> > https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
> >
> > The mdev/vfio parts are exactl
On Wed, 14 Jul 2021 21:20:38 -0300
Jason Gunthorpe wrote:
> +/*
> + * We need to get memory_lock for each device, but devices can share
> mmap_lock,
> + * therefore we need to zap and hold the vma_lock for each device, and only
> then
> + * get each memory_lock.
> + */
> +static int vfio_hot_res
On Thu, 15 Jul 2021 19:11:49 -0300
Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 03:00:55PM -0600, Alex Williamson wrote:
> > On Wed, 14 Jul 2021 21:20:38 -0300
> > Jason Gunthorpe wrote:
> > > +/*
> > > + * We need to get memory_lock for each device, but d
On Fri, 26 Mar 2021 01:09:53 +0800
Fred Gao wrote:
> Before opregion version 2.0 VBT data is stored in opregion mailbox #4,
> but when VBT data exceeds 6KB size and cannot be within mailbox #4
> then from opregion v2.0+, Extended VBT region, next to opregion is
> used to hold the VBT data, so the
Running a Windows guest on a i915-GVTg_V4_2 from an HD 5500 IGD on
v5.12-rc6 results in host logs:
gvt: vgpu 1: lrm access to register (20c0)
gvt: vgpu 1: MI_LOAD_REGISTER_MEM handler error
gvt: vgpu 1: cmd parser error
0x0
0x29
gvt: vgpu 1: scan wa ctx error
gvt: vgpu 1: failed to submit des
On Mon, 12 Apr 2021 10:32:14 -0600
Alex Williamson wrote:
> Running a Windows guest on a i915-GVTg_V4_2 from an HD 5500 IGD on
> v5.12-rc6 results in host logs:
>
> gvt: vgpu 1: lrm access to register (20c0)
> gvt: vgpu 1: MI_LOAD_REGISTER_MEM handler error
> gvt: vgpu 1: cmd
On Tue, 6 Apr 2021 16:40:23 -0300
Jason Gunthorpe wrote:
> vfio_mdev has a number of different objects: mdev_parent, mdev_type and
> mdev_device.
>
> Unfortunately the types of these have been erased in various places
> throughout the API, and this makes it very hard to understand this code or
On Fri, 23 Apr 2021 09:07:09 -0300
Jason Gunthorpe wrote:
> On Fri, Apr 23, 2021 at 11:54:26AM +0800, Zhenyu Wang wrote:
> > On 2021.04.22 10:58:10 -0300, Jason Gunthorpe wrote:
> > > On Thu, Apr 22, 2021 at 03:35:33PM +0200, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
> > > >
> > > >
So revert this one.
>
> Cc: Arnd Bergmann
> Cc: Jason Gunthorpe
> Cc: Alex Williamson
> Signed-off-by: Zhenyu Wang
> ---
> drivers/gpu/drm/i915/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/
On Tue, 27 Apr 2021 13:31:39 +0800
Zhenyu Wang wrote:
> On 2021.04.26 14:40:17 -0300, Jason Gunthorpe wrote:
> > On Mon, Apr 26, 2021 at 10:55:55AM -0600, Alex Williamson wrote:
> > > On Mon, 26 Apr 2021 17:41:43 +0800
> > > Zhenyu Wang wrote:
> >
On Mon, 26 Apr 2021 17:00:02 -0300
Jason Gunthorpe wrote:
> The mdev bus's core part for managing the lifecycle of devices is mostly
> as one would expect for a driver core bus subsystem.
>
> However instead of having a normal 'struct device_driver' and binding the
> actual mdev drivers through
On Tue, 27 Apr 2021 19:20:26 -0300
Jason Gunthorpe wrote:
> On Tue, Apr 27, 2021 at 03:30:42PM -0600, Alex Williamson wrote:
>
> > It'd be really helpful if you could consistently copy at least one
> > list, preferably one monitored by patchwork, for an entire serie
On Fri, 30 Nov 2018 14:51:24 +0800
Zhenyu Wang wrote:
> This trys to make 'kvmgt' module as self loadable instead of loading
> by i915/gvt device model. So hypervisor specific module could be
> stand-alone, e.g only after loading hypervisor specific module, GVT
> feature could be enabled via spec
[cc +Parav]
On Thu, 12 Sep 2019 17:40:10 +0800
Jason Wang wrote:
> Hi all:
>
> During the development of virtio-mdev[1]. I find that mdev needs to be
> extended to support devices other than vfio mdev device. So this
> series tries to extend the mdev to be able to differ from different
> device
On Wed, 18 Sep 2019 01:54:43 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, September 18, 2019 1:31 AM
> >
> > [cc +Parav]
> >
> > On Thu, 12 Sep 2019 17:40:10 +0800
> > Jason Wang wrote:
> >
> > &
On Mon, 23 Sep 2019 21:03:30 +0800
Jason Wang wrote:
> We want to copy from iov to buf, so the direction was wrong.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/vringh.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Why is this included in the series? Seems like an u
On Mon, 23 Sep 2019 21:03:26 +0800
Jason Wang wrote:
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> one example is virtio-mdev[1] driver. This means we need to add device
> class id support in bus ma
On Mon, 23 Sep 2019 12:00:41 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Sep 23, 2019 at 09:45:59AM -0600, Alex Williamson wrote:
> > On Mon, 23 Sep 2019 21:03:30 +0800
> > Jason Wang wrote:
> >
> > > We want to copy from iov to buf, so the directi
On Tue, 24 Sep 2019 21:53:29 +0800
Jason Wang wrote:
> Currently, except for the create and remove, the rest of
> mdev_parent_ops is designed for vfio-mdev driver only and may not help
> for kernel mdev driver. With the help of class id, this patch
> introduces device specific callbacks inside md
On Tue, 24 Sep 2019 21:53:26 +0800
Jason Wang wrote:
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> the first driver could be virtio-mdev. This means we need to add
> device class id support in bus m
On Tue, 24 Sep 2019 21:53:30 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> include/linux/mdev.h| 2 +
> include/linux/virtio_mdev.h | 145 +
On Wed, 25 Sep 2019 10:11:00 -0400
Rob Miller wrote:
> > > On Tue, 24 Sep 2019 21:53:29 +0800
> > > Jason Wang wrote:
> > > > diff --git a/drivers/vfio/mdev/vfio_mdev.c
> > > b/drivers/vfio/mdev/vfio_mdev.c
> > > > index 891cf83a2d9a..95efa054442f 100644
> > > > --- a/drivers/vfio/mdev/vfio_m
On Tue, 7 Jun 2022 20:02:11 -0300
Jason Gunthorpe wrote:
> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> index 61e71c1154be67..f005b644ab9e69 100644
> --- a/drivers/vfio/vfio.c
> +++ b/drivers/vfio/vfio.c
> @@ -1077,8 +1077,20 @@ static void vfio_device_unassign_container(struct
> vfi
On Fri, 17 Jun 2022 16:42:30 -0600
Alex Williamson wrote:
> On Tue, 7 Jun 2022 20:02:11 -0300
> Jason Gunthorpe wrote:
> > diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> > index 61e71c1154be67..f005b644ab9e69 100644
> > --- a/drivers/vfio/vfio.c
>
On Tue, 7 Jun 2022 20:02:12 -0300
Jason Gunthorpe wrote:
> Instead of bouncing the function call to the driver op through a blocking
> notifier just have the iommu layer call it directly.
>
> Register each device that is being attached to the iommu with the lower
> driver which then threads the
On Mon, 4 Jul 2022 21:59:03 -0300
Jason Gunthorpe wrote:
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index b49e2e9db2dc6f..09e0ce7b72324c 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -44,31 +44,19 @@ static int
tainer_q_...@nvidia.com/
And I'm waiting for a respin based on comments for:
Subject: [PATCH v3 0/2] Remove vfio_device_get_from_dev()
Date: Wed, 4 May 2022 16:01:46 -0300
https://lore.kernel.org/all/0-v3-4adf6c1b8e7c+170-vfio_get_from_dev_...@nvidia.com/
If there are others I should be tracki
On Thu, 5 May 2022 21:08:38 -0300
Jason Gunthorpe wrote:
> Prior series have transformed other parts of VFIO from working on struct
> device or struct vfio_group into working directly on struct
> vfio_device. Based on that work we now have vfio_device's readily
> available in all the drivers.
>
Hi Zhi & Zhenyu,
Please review gvt changes below, I'd prefer to get your ack included.
Thanks!
Alex
On Thu, 19 May 2022 14:33:11 -0400
Matthew Rosato wrote:
> Rather than relying on a notifier for associating the KVM with
> the group, let's assume that the association has already been
> made
On Thu, 19 May 2022 14:33:10 -0400
Matthew Rosato wrote:
> As discussed in this thread:
>
> https://lore.kernel.org/kvm/20220516172734.ge1343...@nvidia.com/
>
> Let's remove VFIO_GROUP_NOTIFY_SET_KVM and instead assume the association
> has already been established prior to device_open. For th
On Tue, 19 Jul 2022 21:02:48 -0300
Jason Gunthorpe wrote:
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index a7d2a95796d360..bb1a1677c5c230 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -1226,34 +1226,14
On Wed, 20 Jul 2022 17:08:29 -0300
Jason Gunthorpe wrote:
> On Wed, Jul 20, 2022 at 01:41:13PM -0600, Alex Williamson wrote:
>
> > ie. we don't need the gfn, we only need the iova.
>
> Right, that makes sense
>
> > However then I start to wonder why we&#
On Thu, 21 Jul 2022 12:01:47 -0400
Eric Farman wrote:
> On Wed, 2022-07-20 at 17:04 -0600, Alex Williamson wrote:
> > On Wed, 20 Jul 2022 17:08:29 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Wed, Jul 20, 2022 at 01:41:13PM -0600, Alex Williamson wrote:
>
On Fri, 8 Jul 2022 15:44:18 -0700
Nicolin Chen wrote:
> This is a preparatory series for IOMMUFD v2 patches. It prepares for
> replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
> with IOMMUFD version.
>
> There's a gap between these two versions: the vfio_iommu_type1 version
>
On Tue, 19 Jul 2022 21:02:47 -0300
Jason Gunthorpe wrote:
> This is the last notifier toward the drivers, replace it with a simple op
> callback in the vfio_device_ops.
>
> v4:
> - Rebase over the CCW series
> v3:
> https://lore.kernel.org/r/0-v3-7593f297c43f+56ce-vfio_unmap_notif_...@nvidia.c
On Fri, 22 Jul 2022 16:12:19 -0700
Nicolin Chen wrote:
> On Fri, Jul 22, 2022 at 04:11:29PM -0600, Alex Williamson wrote:
>
> > GVT-g explodes for me with this series on my Broadwell test system,
> > continuously spewing the following:
>
> Thank you for
On Fri, 22 Jul 2022 17:38:25 -0700
Nicolin Chen wrote:
> On Fri, Jul 22, 2022 at 06:18:00PM -0600, Alex Williamson wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Fri, 22 Jul 2022 16:12:19 -0700
> > Nicolin Chen wrote:
> &
On Fri, 22 Jul 2022 19:02:46 -0700
Nicolin Chen wrote:
> This is a preparatory series for IOMMUFD v2 patches. It prepares for
> replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
> with IOMMUFD version.
>
> There's a gap between these two versions: the vfio_iommu_type1 version
On Thu, 7 Apr 2022 03:19:43 -0400
Zhi Wang wrote:
> From: Zhi Wang
>
> To support the new mdev interfaces and the re-factor patches from
> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> MMIO tracking table needs to be separated from GVT-g.
>
Since this commit I'm
...@redhat.com
Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g")
Signed-off-by: Alex Williamson
---
drivers/gpu/drm/i915/intel_gvt_mmio_table.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_gvt_mmio_table.c
b/d
On Wed, 20 Apr 2022 13:43:51 -0300
Jason Gunthorpe wrote:
> On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
> > Hi folks:
> >
> > Here is the PR of gvt-next. Thanks so much for the patience.
> >
> > Mostly it includes the patch bundle of GVT-g re-factor patches for adapting
> > th
On Tue, 26 Apr 2022 08:52:58 -0300
Jason Gunthorpe wrote:
> On Tue, Apr 26, 2022 at 08:42:25AM +, Wang, Zhi A wrote:
> > On 4/26/22 8:37 AM, Jani Nikula wrote:
> > > On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
> > >> Hi folks:
> > >>
> > >> Here is the pull of gvt-next which fixs the compi
On Thu, 28 Apr 2022 15:35:58 -0600
Alex Williamson wrote:
> On Tue, 26 Apr 2022 08:52:58 -0300
> Jason Gunthorpe wrote:
>
> > On Tue, Apr 26, 2022 at 08:42:25AM +, Wang, Zhi A wrote:
> > > On 4/26/22 8:37 AM, Jani Nikula wrote:
> > > > On Tu
On Thu, 21 Apr 2022 13:28:38 -0300
Jason Gunthorpe wrote:
> When the open_device() op is called the container_users is incremented and
> held incremented until close_device(). Thus, so long as drivers call
> functions within their open_device()/close_device() region they do not
> need to worry ab
On Fri, 29 Apr 2022 14:31:49 -0300
Jason Gunthorpe wrote:
> On Thu, Apr 21, 2022 at 01:28:31PM -0300, Jason Gunthorpe wrote:
> > Prior series have transformed other parts of VFIO from working on struct
> > device or struct vfio_group into working directly on struct
> > vfio_device. Based on that
On Sun, 28 Aug 2022 01:10:37 +0800
Kevin Tian wrote:
> From: Yi Liu
>
> and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> sysfs path of the parent, indicating the device is bound to a vfio
> driver, e.g.:
>
> /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
>
> It
On Wed, 31 Aug 2022 06:10:51 +
"Tian, Kevin" wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, August 31, 2022 7:53 AM
> >
> > On Tue, Aug 30, 2022 at 04:18:38PM -0600, Alex Williamson wrote:
> > > On Sun, 28 Aug 2022 01:10:37 +0800
> &
On Thu, 1 Sep 2022 00:46:51 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, September 1, 2022 1:15 AM
> >
> > On Wed, 31 Aug 2022 06:10:51 +
> > "Tian, Kevin" wrote:
> >
> > > > Fro
On Thu, 26 Sep 2019 11:46:55 -0400
"Michael S. Tsirkin" wrote:
> On Wed, Sep 25, 2019 at 10:30:28AM -0600, Alex Williamson wrote:
> > On Wed, 25 Sep 2019 10:11:00 -0400
> > Rob Miller wrote:
> > > > > On Tue, 24 Sep 2019 21:53:29 +0800
> > >
On Fri, 27 Sep 2019 16:25:13 +
Parav Pandit wrote:
> Hi Alex,
>
>
> > -Original Message-
> > From: Alex Williamson
> > Sent: Tuesday, September 24, 2019 6:07 PM
> > To: Jason Wang
> > Cc: k...@vger.kernel.org; linux-s...@vger.kernel.org; li
On Fri, 11 Oct 2019 16:15:51 +0800
Jason Wang wrote:
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index b558d4cfd082..724e9b9841d8 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -45,6 +45,12 @@ void mdev_set_drvdata(stru
On Tue, 15 Oct 2019 20:17:01 +0800
Jason Wang wrote:
> On 2019/10/15 下午6:41, Cornelia Huck wrote:
> > On Fri, 11 Oct 2019 16:15:54 +0800
> > Jason Wang wrote:
> >
> >> Currently, except for the create and remove, the rest of
> >> mdev_parent_ops is designed for vfio-mdev driver only and may no
On Wed, 16 Oct 2019 15:31:25 +
Parav Pandit wrote:
> > -Original Message-
> > From: Cornelia Huck
> > Sent: Wednesday, October 16, 2019 3:53 AM
> > To: Parav Pandit
> > Cc: Alex Williamson ; Jason Wang
> > ; k...@vger.kernel.org; linux
On Wed, 16 Oct 2019 20:48:06 +
Parav Pandit wrote:
> > From: Alex Williamson
> > On Wed, 16 Oct 2019 15:31:25 +
> > Parav Pandit wrote:
> > > > From: Cornelia Huck
> > > > Parav Pandit wrote:
> > > > > > From: Alex Williamso
On Thu, 17 Oct 2019 17:07:55 +0200
Cornelia Huck wrote:
> On Thu, 17 Oct 2019 18:48:33 +0800
> Jason Wang wrote:
>
> > Currently, except for the create and remove, the rest of
> > mdev_parent_ops is designed for vfio-mdev driver only and may not help
> > for kernel mdev driver. With the help of
On Thu, 17 Oct 2019 18:48:34 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/mdev_core.c | 12 +++
> include/linux/mdev.h | 4 +
> includ
On Wed, 23 Oct 2019 21:07:48 +0800
Jason Wang wrote:
> Add support to parse mdev class id table.
>
> Reviewed-by: Parav Pandit
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/vfio_mdev.c | 2 ++
> scripts/mod/devicetable-offsets.c | 3 +++
> scripts/mod/file2alias.c | 10
On Wed, 23 Oct 2019 21:07:47 +0800
Jason Wang wrote:
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> the first driver could be virtio-mdev. This means we need to add
> device class id support in bus m
On Wed, 23 Oct 2019 21:07:50 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/mdev_core.c| 20
> drivers/vfio/mdev/mdev_private.h | 2 +
>
On Thu, 24 Oct 2019 11:27:36 +0800
Jason Wang wrote:
> On 2019/10/24 上午5:42, Alex Williamson wrote:
> > On Wed, 23 Oct 2019 21:07:47 +0800
> > Jason Wang wrote:
> >
> >> Mdev bus only supports vfio driver right now, so it doesn't implement
> >>
On Thu, 24 Oct 2019 11:31:04 +0800
Jason Wang wrote:
> On 2019/10/24 上午5:42, Alex Williamson wrote:
> > On Wed, 23 Oct 2019 21:07:48 +0800
> > Jason Wang wrote:
> >
> >> Add support to parse mdev class id table.
> >>
> >> Reviewed-
On Thu, 24 Oct 2019 13:46:36 -0600
Alex Williamson wrote:
> On Thu, 24 Oct 2019 11:27:36 +0800
> Jason Wang wrote:
>
> > On 2019/10/24 上午5:42, Alex Williamson wrote:
> > > On Wed, 23 Oct 2019 21:07:47 +0800
> > > Jason Wang wrote:
> > >
>
On Thu, 24 Oct 2019 11:51:35 +0800
Jason Wang wrote:
> On 2019/10/24 上午5:57, Alex Williamson wrote:
> > On Wed, 23 Oct 2019 21:07:50 +0800
> > Jason Wang wrote:
> >
> >> This patch implements basic support for mdev driver that supports
> >> vi
On Mon, 4 Nov 2019 20:39:47 +0800
Jason Wang wrote:
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> the first driver could be virtio-mdev. This means we need to add
> device class id support in bus m
On Mon, 4 Nov 2019 20:39:49 +0800
Jason Wang wrote:
> Currently, except for the create and remove, the rest of
> mdev_parent_ops is designed for vfio-mdev driver only and may not help
> for kernel mdev driver. With the help of class id, this patch
> introduces device specific callbacks inside md
On Mon, 4 Nov 2019 20:39:50 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/mdev_core.c| 20
> drivers/vfio/mdev/mdev_private.h | 2 +
>
On Tue, 5 Nov 2019 11:52:41 +0800
Jason Wang wrote:
> On 2019/11/5 上午5:50, Alex Williamson wrote:
> > On Mon, 4 Nov 2019 20:39:50 +0800
> > Jason Wang wrote:
> >
> >> This patch implements basic support for mdev driver that supports
> >> vi
On Tue, 5 Nov 2019 17:50:25 +0100
Cornelia Huck wrote:
> On Tue, 5 Nov 2019 17:32:37 +0800
> Jason Wang wrote:
>
> > Currently, except for the create and remove, the rest of
> > mdev_parent_ops is designed for vfio-mdev driver only and may not help
> > for kernel mdev driver. With the help of
On Tue, 5 Nov 2019 17:32:38 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/mdev_core.c| 21 +
> drivers/vfio/mdev/mdev_private.h | 2 +
>
On Tue, 5 Nov 2019 17:32:34 +0800
Jason Wang wrote:
> Hi all:
>
> There are hardwares that can do virtio datapath offloading while
> having its own control path. This path tries to implement a mdev based
> unified API to support using kernel virtio driver to drive those
> devices. This is done
On Wed, 6 Nov 2019 11:56:46 +0800
Jason Wang wrote:
> On 2019/11/6 上午1:58, Alex Williamson wrote:
> > On Tue, 5 Nov 2019 17:32:34 +0800
> > Jason Wang wrote:
> >
> >> Hi all:
> >>
> >> There are hardwares that can do virtio datapath offload
On Wed, 6 Nov 2019 14:25:23 -0500
"Michael S. Tsirkin" wrote:
> On Wed, Nov 06, 2019 at 12:03:12PM -0700, Alex Williamson wrote:
> > On Wed, 6 Nov 2019 11:56:46 +0800
> > Jason Wang wrote:
> >
> > > On 2019/11/6 上午1:58, Alex Williamson wrote:
&g
On Wed, 6 Nov 2019 14:50:30 -0800
Randy Dunlap wrote:
> On 11/5/19 11:05 PM, Jason Wang wrote:
> > diff --git a/samples/Kconfig b/samples/Kconfig
> > index c8dacb4dda80..13a2443e18e0 100644
> > --- a/samples/Kconfig
> > +++ b/samples/Kconfig
> > @@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY
>
On Mon, 18 Jan 2021 20:38:34 +0800
Fred Gao wrote:
> Before opregion version 2.0 VBT data is stored in opregion mailbox #4,
> However, When VBT data exceeds 6KB size and cannot be within mailbox #4
> starting from opregion v2.0+, Extended VBT region, next to opregion, is
> used to hold the VBT da
On Thu, 3 Dec 2020 01:12:49 +0800
Fred Gao wrote:
> When VBT data exceeds 6KB size and cannot be within mailbox #4 starting
> from opregion v2.0+, Extended VBT region, next to opregion, is used to
> hold the VBT data, so the total size will be opregion size plus
> extended VBT region size.
>
>
On Thu, 3 Dec 2020 09:21:03 +
"Gao, Fred" wrote:
> Thanks Alex for the timely review.
>
> > -Original Message-
> > From: Alex Williamson
> > Sent: Thursday, December 3, 2020 2:57 AM
> > To: Gao, Fred
> > Cc: k...@vger.kernel.org
On Tue, 2 Mar 2021 21:02:20 +0800
Fred Gao wrote:
> Before opregion version 2.0 VBT data is stored in opregion mailbox #4,
> However, When VBT data exceeds 6KB size and cannot be within mailbox #4
> starting from opregion v2.0+, Extended VBT region, next to opregion, is
> used to hold the VBT da
On Tue, 3 Nov 2020 02:01:20 +0800
Fred Gao wrote:
> Bypass the IGD initialization when -ENODEV returns,
> that should be the case if opregion is not available for IGD
> or within discrete graphics device's option ROM,
> or host/lpc bridge is not found.
>
> Then use of -ENODEV here means no spec
On Fri, 10 Jul 2020 01:37:07 +0800
Fred Gao wrote:
> Bypass the IGD initialization for Intel's dgfx devices with own expansion
> ROM and the host/LPC bridge config space are no longer accessed.
>
> Cc: Zhenyu Wang
> Cc: Xiong Zhang
> Cc: Hang Yuan
> Cc: Stuart Summers
> Signed-off-by: Lucas
On Wed, 30 Sep 2020 00:10:38 +0800
Fred Gao wrote:
> Bypass the IGD initialization for Intel's dgfx devices with own expansion
> ROM and the host/LPC bridge config space are no longer accessed.
>
> v2: simply test if discrete or integrated gfx device
> with root b
On Wed, 12 Apr 2017 20:20:00 +0800
Xiong Zhang wrote:
> Stolen memory isn't a standard pci resource and exists in RMRR which has
> identity mapping in iommu table, IGD could access stolen memory in host OS.
> While according to 'commit c875d2c1b808 ("iommu/vt-d: Exclude devices using
> RMRRs from
On Thu, 13 Apr 2017 05:44:18 +
"Zhang, Xiong Y" wrote:
> > On Wed, 12 Apr 2017 20:20:00 +0800
> > Xiong Zhang wrote:
> >
> > > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > > identity mapping in iommu table, IGD could access stolen memory in host
> > OS.
On Thu, 4 May 2017 03:09:40 +
"Chen, Xiaoguang" wrote:
> Hi Alex, do you have any comments for this interface?
>
> >-Original Message-
> >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> >Behalf Of Chen, Xiaoguang
> >Sent: Wednesday, May 03, 2017 9:39 AM
On Fri, 05 May 2017 08:55:31 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > >>Hmm, that looks like a rather strange way to return a file descriptor.
> > > >>
> > > >>What is the reason to not use ioctls on the vfio file handle, like
> > > >>older version of these patches did?
> > > >If I underst
On Mon, 08 May 2017 13:07:10 +0300
Joonas Lahtinen wrote:
> On la, 2017-05-06 at 02:58 +, Zhang, Xiong Y wrote:
> > >
> > > On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote:
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > + David and Jon
> > > > > >
> > > >
On Thu, 11 May 2017 15:27:53 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > While read the framebuffer region we have to tell the vendor driver which
> > framebuffer we want to read? There are two framebuffers now in KVMGT that
> > is primary and cursor.
> > There are two methods to implement this:
On Fri, 12 May 2017 02:12:10 +
"Chen, Xiaoguang" wrote:
> Hi Alex and Gerd,
>
> >-Original Message-
> >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> >Behalf Of Alex Williamson
> >Sent: Thursday, May 11, 2017 11
On Fri, 12 May 2017 11:12:05 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > If the contents of the framebuffer change or if the parameters of the
> > framebuffer change? I can't image that creating a new dmabuf fd for
> > every visual change within the framebuffer would be efficient, but I
> > don't
t; >To: Chen, Xiaoguang
> >Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org;
> >linux-
> >ker...@vger.kernel.org; zhen...@linux.intel.com; Alex Williamson
> >; Lv, Zhiyuan ; intel-gvt-
> >d...@lists.freedesktop.org; Wang, Zhi A
> >Subject: Re: [RFC PATCH 6/6
On Mon, 15 May 2017 03:36:50 +
"Chen, Xiaoguang" wrote:
> Hi Alex and Gerd,
>
> >-Original Message-
> >From: Alex Williamson [mailto:alex.william...@redhat.com]
> >Sent: Saturday, May 13, 2017 12:38 AM
> >To: Gerd Hoffmann
> >Cc
On Wed, 21 Mar 2018 10:08:03 +0100
Gerd Hoffmann wrote:
> On unknown/unhandled ioctls the driver should return an error, so
> userspace knows it tried to use something unsupported.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
>
1 - 100 of 391 matches
Mail list logo
