> From: Jason Gunthorpe
> Sent: Wednesday, March 24, 2021 1:56 AM
>
> At some point there may have been some reason for this weird split in this
> driver, but today only the VFIO side is actually implemented.
>
> However, it got messed up at some point and mdev code was put in gvt.c and
> is pret
> From: Jason Gunthorpe
> Sent: Wednesday, March 24, 2021 1:56 AM
>
> intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
> supported_type_groups array, so the type_group_id is also the index into
> gvt->types. Use it directly and remove the string matching.
>
> Signed-off-by: Jason G
> From: Jason Gunthorpe
> Sent: Wednesday, March 24, 2021 1:56 AM
>
> The kobj here is a type-erased version of mdev_type, which is already
> stored in the struct mdev_device being passed in. It was only ever used to
> compute the type_group_id, which is now extracted directly from the mdev.
>
>
> From: Jason Gunthorpe
> Sent: Wednesday, March 24, 2021 1:56 AM
>
> The driver core standard is to pass in the properly typed object, the
> properly typed attribute and the buffer data. It stems from the root
> kobject method:
>
> ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *
> From: Jason Wang
> Sent: Thursday, September 12, 2019 5:40 PM
>
> Mdev bus only support 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
> id support in b
> From: Jason Wang
> Sent: Thursday, September 12, 2019 5:40 PM
>
> Currently, except for the crate and remove. The rest fields of
> mdev_parent_ops is just designed for vfio-mdev driver and may not help
> for kernel mdev driver. So follow the device id support by previous
> patch, this patch intr
> 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:
>
> > Hi all:
> >
> > During the development of virtio-mdev[1]. I find that mdev needs to be
> > extended to support devices other than vfio mdev devi
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Tuesday, September 17, 2019 6:17 PM
>
> On 2019/9/17 下午4:09, Tian, Kevin wrote:
> >> From: Jason Wang
> >> Sent: Thursday, September 12, 2019 5:40 PM
> >>
> >> Currently, exc
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Tuesday, September 24, 2019 9:53 PM
>
> Hi all:
>
> There are hardware 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
> From: Jason Wang
> Sent: Tuesday, September 24, 2019 9:53 PM
>
> 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 suppo
> From: Alex Williamson
> Sent: Wednesday, September 25, 2019 7:07 AM
>
> 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. W
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Tuesday, September 24, 2019 9:54 PM
>
> 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/lin
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
>
> 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 v
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
>
> There's only one caller that checks its return value with a WARN_ON_ONCE,
> while all other callers do not check return value at all. So simplify the
> API to return void by embedding similar WARN_ON_ONCEs.
While this change keeps
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
> /*
> - * Pin a set of guest PFNs and return their associated host PFNs for local
> + * Pin contiguous guest pages and return their associated host pages for
> local
can we replace 'guest' with 'user'?
> * domain only.
> * @device
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
>
> Following the updated vfio_pin/unpin_pages(), use the simpler "iova".
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Kevin Tian
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
>
> Most of the callers of vfio_pin_pages() want "struct page *" and the
> low-level mm code to pin pages returns a list of "struct page *" too.
> So there's no gain in converting "struct page *" to PFN in between.
>
> Replace the outp
> From: Matthew Rosato
> Sent: Thursday, May 19, 2022 5:26 AM
>
> Rather than relying on a notifier for associating the KVM with
> the group, let's assume that the association has already been
> made prior to device_open. The first time a device is opened
> associate the group KVM with the device
> From: h...@infradead.org
> Sent: Thursday, May 19, 2022 2:48 PM
>
> On Thu, May 19, 2022 at 06:43:06AM +, Tian, Kevin wrote:
> > > This fixes a user-triggerable oops in GVT.
> >
> > No changelog.
>
> ??
>
> the cover latter clearly states what
> From: Jason Gunthorpe
> Sent: Wednesday, June 8, 2022 7:02 AM
>
> Instead of having drivers register the notifier with explicit code just
> have them provide a dma_unmap callback op in their driver ops and rely on
> the core code to wire it up.
>
> Suggested-by: Christoph Hellwig
> Reviewed-by
> From: Jason Gunthorpe
> Sent: Wednesday, June 8, 2022 7:02 AM
>
> 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 thre
> From: Jason Gunthorpe
> Sent: Wednesday, June 8, 2022 7:27 PM
>
> On Wed, Jun 08, 2022 at 03:47:12AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, June 8, 2022 7:02 AM
> > >
> > > Instead of bouncing the f
> From: Jason Gunthorpe
> Sent: Thursday, April 14, 2022 7:12 AM
>
> On Wed, Apr 13, 2022 at 09:08:40PM +, Wang, Zhi A wrote:
> > On 4/13/22 8:04 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 07:17:52PM +, Wang, Zhi A wrote:
> > >> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> >
> From: Wang, Zhi A
> Sent: Thursday, April 14, 2022 5:09 AM
>
> > Or is it that only the page table levels themselves are GFNs and the
> > actual DMA's are IOVA? The unclear mixing of GFN as IOVA in the code
> > makes it inscrutible.
> >
>
> No. Even the HW is capable of controlling the level o
> From: Jason Gunthorpe
> Sent: Thursday, April 14, 2022 10:22 PM
>
> On Thu, Apr 14, 2022 at 09:51:49AM -0400, Matthew Rosato wrote:
> > On 4/12/22 11:53 AM, Jason Gunthorpe wrote:
> > > When the open_device() op is called the container_users is incremented
> and
> > > held incremented until clo
> From: Jason Gunthorpe
> Sent: Friday, April 15, 2022 8:07 PM
>
> On Fri, Apr 15, 2022 at 02:32:08AM +, Tian, Kevin wrote:
>
> > While it's a welcomed fix is it actually related to this series? The point
> > of this patch is that those functions are called
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> All callers have a struct vfio_device trivially available, pass it in
> directly and avoid calling the expensive vfio_group_get_from_dev().
>
> To support the unconverted kvmgt mdev driver add
> mdev_legacy_get_vfio_device() whic
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Every caller has a readily available vfio_device pointer, use that instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra refcountings,
> and
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Every caller has a readily available vfio_device pointer, use that instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra refcountings,
> and
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
> reason to use a group interface here, kvmgt has easy access to a
> vfio_device.
>
> Delete kvmgt_vdev::vfio_group since these calls were the last users
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Now that callers have been updated to use the vfio_device APIs the driver
> facing group interface is no longer used, delete it:
>
> - vfio_group_get_external_user_from_dev()
> - vfio_group_pin_pages()
> - vfio_group_unpin_pages
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> 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
> From: Jason Gunthorpe
> Sent: Saturday, April 23, 2022 2:00 AM
>
> On Fri, Apr 22, 2022 at 01:50:00AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Friday, April 22, 2022 12:29 AM
> > >
> > > Every caller has a readily
This missed a Suggested-by from Jason. Will add in next version.
> From: Tian, Kevin
> Sent: Sunday, August 28, 2022 1:11 AM
>
> ccw is the only exception which cannot use vfio_alloc_device() because
> its private device structure is designed to serve both mdev and parent.
>
nst-variable]
drivers/vfio/platform/vfio_platform_common.c:608:37: warning: unused variable
'vfio_platform_ops' [-Wunused-const-variable]
> From: Tian, Kevin
> Sent: Sunday, August 28, 2022 1:10 AM
>
> The idea is to let vfio core manage the vfio_device life cycle instead
> of duplica
> From: Jason Gunthorpe
> Sent: Tuesday, August 30, 2022 11:10 PM
>
> On Tue, Aug 30, 2022 at 09:42:42AM -0400, Anthony Krowiak wrote:
>
> > > +/*
> > > + * Alloc and initialize vfio_device so it can be registered to vfio
> > > + * core.
> > > + *
> > > + * Drivers should use the wrapper vfio_al
> 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
> > Kevin Tian wrote:
> >
> > > From: Yi Liu
> > >
> > > and replace kref. With it a 'vfio-dev/vfioX' node is created un
> From: Jason Gunthorpe
> Sent: Wednesday, August 31, 2022 8:23 AM
>
> On Sun, Aug 28, 2022 at 01:10:32AM +0800, Kevin Tian wrote:
> > From: Yi Liu
> >
> > Export symbol of vfio_release_device_set() so fsl-mc @init can handle
> > the error path cleanly instead of assuming certain vfio core API c
> From: Jason Gunthorpe
> Sent: Wednesday, August 31, 2022 8:32 AM
>
> On Sun, Aug 28, 2022 at 01:10:37AM +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 vfi
> From: Jason Gunthorpe
> Sent: Wednesday, August 31, 2022 8:35 AM
>
> On Sun, Aug 28, 2022 at 01:10:22AM +0800, Kevin Tian wrote:
>
> > Kevin Tian (6):
> > vfio: Add helpers for unifying vfio_device life cycle
> > drm/i915/gvt: Use the new device life cycle helpers
> > vfio/platform: Use
> From: Alex Williamson
> Sent: Thursday, September 1, 2022 1:15 AM
>
> On Wed, 31 Aug 2022 06:10:51 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, August 31, 2022 7:53 AM
> > >
> > >
> From: Tian, Kevin
> Sent: Thursday, September 1, 2022 10:38 PM
>
> +static const struct vfio_device_ops vfio_amba_ops= {
Above missed a space after vfio_amba_ops.
> From: Tian, Kevin
> Sent: Thursday, September 1, 2022 10:38 PM
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev
> b/Documentation/ABI/testing/sysfs-devices-vfio-dev
> new file mode 100644
> index ..e21424fd9666
> --- /dev/null
> +++
> From: Christoph Hellwig
> Sent: Tuesday, September 6, 2022 5:42 PM
>
> What is the point? This adds indirect calls, and actually creates
> more boilerplate code in the drivers. i.g. when using this code there
> is more, and harder to read code.
The point is to align with struct device life cy
> From: Eric Auger
> Sent: Thursday, September 8, 2022 3:28 AM
> > +/*
> > + * Alloc and initialize vfio_device so it can be registered to vfio
> > + * core.
> > + *
> > + * Drivers should use the wrapper vfio_alloc_device() for allocation.
> > + * @size is the size of the structure to be allocate
ping @Eric Farman.
ccw is the only tricky player in this series. Please help take a look in case of
any oversight here.
> From: Tian, Kevin
> Sent: Thursday, September 1, 2022 10:38 PM
>
> ccw is the only exception which cannot use vfio_alloc_device() because
> its private devi
> From: Eric Farman
> Sent: Friday, September 9, 2022 4:51 AM
>
> On Thu, 2022-09-08 at 07:19 +, Tian, Kevin wrote:
> > ping @Eric Farman.
> >
> > ccw is the only tricky player in this series. Please help take a look
> > in case of
> > any oversight h
> From: Jason Gunthorpe
> Sent: Thursday, September 8, 2022 8:37 PM
>
> On Thu, Sep 08, 2022 at 11:39:07AM +0200, Eric Auger wrote:
>
> > >> I am not totally clear about remaining 'struct device *dev;' in
> > >> vfio_device struct. I see it used in some places. Is it supposed to
> > >> disappear
> From: Ethan Zhao
> Sent: Friday, September 9, 2022 4:24 PM
>
> Hi, Kevin,
>
> 在 2022/9/9 18:22, Kevin Tian 写道:
> > The idea is to let vfio core manage the vfio_device life cycle instead
> > of duplicating the logic cross drivers. This is also a preparatory
> > step for adding struct device int
> From: Jason Wang
> Sent: Wednesday, September 25, 2019 8:45 PM
>
>
> On 2019/9/25 下午5:09, Tian, Kevin wrote:
> >> From: Jason Wang [mailto:jasow...@redhat.com]
> >> Sent: Tuesday, September 24, 2019 9:54 PM
> >>
> >> This patch implements basi
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, April 12, 2017 9:22 PM
>
[...]
> By my limited understanding of VT-d details: The stolen memory is never
> directly accessed by i915 driver (because CPU access doesn't work even
> in DOM0). It is only used through
Curious why leaking BIOS configuration to VM is a security problem... Can
someone elaborate this view?
From: Wang, Zhi A
Sent: Friday, May 27, 2016 6:05 PM
To: intel-gfx@lists.freedesktop.org
Cc: joonas.lahti...@linux.intel.com; Chris Wilson; Vetter, Daniel;
tvrtko.ursu...@linux.intel.com; Tian
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Friday, June 03, 2016 5:47 PM
>
> On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote:
> > This patch introduces the support of LRC context signle submission.
>
> "single"
>
> > As GVT context may come from different guests, w
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Friday, May 27, 2016 7:39 PM
>
> On pe, 2016-05-27 at 10:09 +, Tian, Kevin wrote:
> > Curious why leaking BIOS configuration to VM is a security problem…
> > Can someone elaborate this view?
&
n there won’t be leaking happened I
> > think. Even we wrote a dedicated little program, we would do the same
> > thing.
> >
> > From: Wang, Zhi A
> > Sent: Friday, May 27, 2016 12:59 PM
> > To: joonas.lahti...@linux.intel.com; 'Chris Wilson' ; Vetter, Danie
> From: Wang, Zhi A
> Sent: Tuesday, June 14, 2016 9:21 PM
>
> This patchset introduces the implementation of GVT context. GVT
> context is a special GEM context used by GVT-g. GVT-g uses it as the shadow
> context.It doesn't have a drm client nor a PPGTT. And it requires a larger
> ring buffer wi
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, June 08, 2016 5:23 PM
>
> On pe, 2016-06-03 at 12:36 +, Tian, Kevin wrote:
> > >
> > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > > Sent: Friday,
> From: Song, Jike
> Sent: Friday, November 20, 2015 1:52 PM
>
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On T
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Thursday, November 19, 2015 4:41 PM
>
> Hi,
>
> > > Another area of extension is how to expose a framebuffer to QEMU for
> > > seamless integration into a SPICE/VNC channel. For this I believe we
> > > could use a new region, much like w
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 20, 2015 4:03 AM
>
> > >
> > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > supports modular bus drivers and IOMMU
> From: Tian, Kevin
> Sent: Friday, November 20, 2015 3:10 PM
> > > >
> > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > > supports modul
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Friday, November 20, 2015 4:26 PM
>
> Hi,
>
> > > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > > explain how the guest framebuffer can be accessed then.
> >
> > You can check "fb_decoder.h". One thing to clar
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, November 19, 2015 6:35 PM
>
> On Thu, Nov 19, 2015 at 06:20:23PM +0800, Zhi Wang wrote:
> > Hi Gurus:
> > I'm curious about the register GFX_FLSH_CNT(0x101008) in
> > i915_gem_gtt.c. Does these register exist in re
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, November 20, 2015 5:40 PM
>
> On Fri, Nov 20, 2015 at 09:23:12AM +, Tian, Kevin wrote:
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Thursday, November 19, 2
> From: Tian, Kevin
> Sent: Friday, November 20, 2015 4:36 PM
>
> >
> > > > So, for non-opengl rendering qemu needs the guest framebuffer data so it
> > > > can feed it into the vnc server. The vfio framebuffer region is meant
> > > > to s
> From: Wang, Zhi A
> Sent: Tuesday, February 16, 2016 12:04 AM
>
> The better design idea is to reuse the data structures and helper
> functions, but have new top-level entry functions for creating e.g. a
> xengt lrc context. So e.g. have a lrc init function for xengt which
> takes the setup stuf
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> new file mode 100644
> index 000..52cfa32
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
[...]
> +
> +#include
> +#include
would this inclu
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 1c0366a..2a6d6fe 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -479,6 +479,40 @@ static void
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
> -static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
> +static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt, int
> address_space_mode)
address_space_mode -> address_bits?
> {
> int ret;
>
> @@ -1518,7 +1524,7 @@ sta
submission context we will restore the render registers when the GVT context
> is
> scheduled-out by HW.
Thanks for explanation. It's fine then.
>
> > -Original Message-
> > From: Tian, Kevin
> > Sent: Wednesday, February 24, 2016 4:56 PM
> > To:
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> index 52cfa32..2099b7e 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> @@ -348,6 +348,10 @@ void *gvt_create_pgt_de
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, February 23, 2016 8:54 PM
> > diff --git a/drivers/gpu/drm/i915/gvt/Makefile
> > b/drivers/gpu/drm/i915/gvt/Makefile
> > new file mode 100644
> > index 000..959305f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i91
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
>
> Let the core logic of context creation service creats the GEM context by
> context creation params.
>
> Now it provides following options for context creation:
> - Need to create legacy context for this GEM context?
> - Need to c
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
> diff --git a/drivers/gpu/drm/i915/intel_lrc.h
> b/drivers/gpu/drm/i915/intel_lrc.h
> index e6cda3e..528c4fb 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/intel_lrc.h
> @@ -97,10 +97,18 @@ static inline
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, February 23, 2016 8:42 PM
>
> Hi,
>
> Code is looking a lot better.
>
> A general question still; why you seem to be preferring multi-stage
> alloc and destroy?
One reason for multi-stage, IMO, is that GVT needs t
> From: Wang, Zhi A
> Sent: Tuesday, February 23, 2016 9:23 PM
> >> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> >> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> >> @@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private
> *dev_priv)
> >>goto err;
> >>}
> >>
> >> + dev_priv->gv
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
>
> Previously the PDPs inside the ring context are updated at:
>
> - When populate a LRC context
> - Before submitting a LRC context (only for 32 bit PPGTT, as the amount
> of used PDPs may change)
>
> This patch postpones the PDPs
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
>
> For flexible GEM context creation, we factor out __i915_gem_create_context
> as the core logic of creation a GEM context. After the refactor, it more
> likesa context creation servcie, which is able to create context by
> explicit
> From: Wang, Zhi A
> Sent: Thursday, February 18, 2016 7:42 PM
>
> This patchset is used to discuss and finalize the i915 changes required by
> GVT context. Previously we have discussed about how to hack i915 to meet
> GVT context requirement, and thanks for the idea and comments.
>
> In this pa
I had some replies to this mailing list yesterday, but received below
notification:
---
Delivery is delayed to these recipients or groups:
intel-gfx@lists.freedesktop.org
Subject: RE: [RFCv2 PATCH 00/14] gvt: Hacking i915 for GVT context requirement
This message hasn't been delivered yet. Deli
> From: Zhiyuan Lv
> Sent: Tuesday, March 08, 2016 9:26 AM
>
> > > The igvt device model is responsible for injecting vblank interrupts to
> > > VMs
> > > for i915 running inside. Currently we have a timer for the regular vblank
> > > injection. So if needed, host i915 can notify gvt device model
> From: Zhiyuan Lv
> Sent: Thursday, March 03, 2016 5:51 PM
>
> Dear i915 developers,
>
> Here I have one topic hoping to get your comments and suggestions.
> Basically it is about graphics virtualization(igvt-g), for the purpose
> of host system to get virtual machine's framebuffer. We would lik
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Tuesday, March 08, 2016 4:37 PM
>
> Hi,
>
> > btw I don't think this vblank issue would be very significant. The main
> > targeted usage of GVT-g is for server virtualization/cloud, where
> > a remoting protocol is required for customer t
It's also the style how CPU page table is managed...
> From: Wang, Zhi A
> Sent: Wednesday, November 23, 2016 3:37 PM
>
> Hi Chris, thanks for the reply! Without this patch, we have to do pattern
> scan to identify
> if the page is still being used as a PT page. :( It's complicated.
>
> Origina
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, November 19, 2015 2:12 AM
>
> [cc +qemu-devel, +paolo, +gerd]
>
> On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > Hi all,
> >
> > We are pleased to announce another update of Intel GVT-g for Xen.
> >
> > Intel G
> From: john.c.harri...@intel.com
> Sent: Tuesday, January 12, 2016 2:42 AM
>
> From: John Harrison
>
> Implemented a batch buffer submission scheduler for the i915 DRM driver.
>
> The general theory of operation is that when batch buffers are
> submitted to the driver, the execbuffer() code as
> From: akash.g...@intel.com
> Sent: Saturday, January 09, 2016 7:32 PM
>
[...]
>
> There is a provision to keep TR-TT Tables in virtual space, where the pages of
> TRTT tables will be mapped to PPGTT. This is the adopted mode, as in this mode
> UMD will have a full control on TR-TT management,
> From: Gordon, David S
> Sent: Tuesday, January 12, 2016 9:49 PM
>
> On 12/01/2016 11:43, John Harrison wrote:
> > On 12/01/2016 04:37, Tian, Kevin wrote:
> >>> From: john.c.harri...@intel.com
> >>> Sent: Tuesday, January 12, 2016 2:42 AM
> >>&
From: Dong, Chuanxiao
> > Sent: Wednesday, March 22, 2017 2:35 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: intel-gvt-...@lists.freedesktop.org; Dong, Chuanxiao
> > ; Zheng, Xiao ; Tian,
> > Kevin
> > Subject: [PATCH v3] drm/i915/scheduler: add gvt notificat
> From: Alex Williamson
> Sent: Wednesday, April 12, 2023 5:58 AM
>
> On Tue, 11 Apr 2023 15:40:07 -0300
> Jason Gunthorpe wrote:
>
> > On Tue, Apr 11, 2023 at 11:11:17AM -0600, Alex Williamson wrote:
> > > [Appears the list got dropped, replying to my previous message to re-add]
> >
> > Wowo t
> From: Jason Gunthorpe
> Sent: Wednesday, April 12, 2023 8:01 AM
>
> I see this problem as a few basic requirements from a qemu-like
> application:
>
> 1) Does the configuration I was given support reset right now?
> 2) Will the configuration I was given support reset for the duration
> of
> From: Jason Gunthorpe
> Sent: Wednesday, April 12, 2023 11:06 PM
>
> On Wed, Apr 12, 2023 at 07:27:43AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, April 12, 2023 8:01 AM
> > >
> > > I see this prob
> From: Jason Gunthorpe
> Sent: Thursday, April 13, 2023 4:07 AM
>
>
> > in which case we need c) a way to
> > report the overall set of affected devices regardless of ownership in
> > support of 4), BDF?
>
> Yes, continue to use INFO unmodified.
>
> > Are we back to replacing group-ids with d
> From: Alex Williamson
> Sent: Friday, April 14, 2023 2:07 AM
>
> We had already iterated a proposal where the group-id is replaced with
> a dev-id in the existing ioctl and a flag indicates when the return
> value is a dev-id vs group-id. This had a gap that userspace cannot
> determine if a r
> From: Jason Gunthorpe
> Sent: Monday, April 17, 2023 9:39 PM
>
> On Fri, Apr 14, 2023 at 09:11:30AM +, Tian, Kevin wrote:
>
> > The only corner case with this option is when a user mixes group
> > and cdev usages. iirc you mentioned it's a valid usage to be
> From: Alex Williamson
> Sent: Tuesday, April 18, 2023 4:07 AM
>
> On Mon, 17 Apr 2023 16:31:56 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > mixing groups, cd
> From: Alex Williamson
> Sent: Tuesday, April 18, 2023 12:11 PM
>
> On Tue, 18 Apr 2023 03:24:46 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, April 18, 2023 4:07 AM
> > >
> > >
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> -static inline bool vfio_device_is_noiommu(struct vfio_device *vdev)
> +static inline int vfio_device_set_noiommu(struct vfio_device *device)
> {
> - return IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> -vdev->group->type ==
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
> @@ -121,7 +128,8 @@ static void vfio_emulated_unmap(void *data,
> unsigned long iova,
> {
> struct vfio_device *vdev = data;
>
> - if (vdev->ops->dma_unmap)
> + /* noiommu devices cannot do map/unmap */
> + if (vdev
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> This prepares to add another method for hot reset. The major hot reset logic
> are moved to vfio_pci_ioctl_pci_hot_reset_groups().
>
> No functional change is intended.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Jason Gun
1 - 100 of 285 matches
Mail list logo
