[Intel-gfx] Intel-gfx Digest, Vol 185, Issue 285
Matt Jack
kiss_my_axe4ever at icloud.com
Wed Jun 14 04:33:53 UTC 2023
Man, can someone reply to me is this exactly what’s going on to my devices? What do you want me to do seriously man it’s getting old. Do you want me to compile and make one of these units and then my device will be OK again like what is the deal?
Sent from my iPhone
> On Jun 13, 2023, at 11:24 PM, intel-gfx-request at lists.freedesktop.org wrote:
>
> Send Intel-gfx mailing list submissions to
> intel-gfx at lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> or, via email, send a message with subject or body 'help' to
> intel-gfx-request at lists.freedesktop.org
>
> You can reach the person managing the list at
> intel-gfx-owner at lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Intel-gfx digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH] drm/i915/guc/slpc: Apply min softlimit correctly
> (Dixit, Ashutosh)
> 2. Re: [PATCH v3 00/28] drm/i915/gvt: KVM: KVMGT fixes and
> page-track cleanups (Ma, Yongwei)
> 3. Re: [PATCH v12 21/24] vfio: Determine noiommu device in
> __vfio_register_dev() (Liu, Yi L)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 13 Jun 2023 19:25:42 -0700
> From: "Dixit, Ashutosh" <ashutosh.dixit at intel.com>
> To: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
> Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Apply min
> softlimit correctly
> Message-ID: <87zg52ye3d.wl-ashutosh.dixit at intel.com>
> Content-Type: text/plain; charset=US-ASCII
>
>> On Fri, 09 Jun 2023 15:02:52 -0700, Vinay Belgaumkar wrote:
>>
>
> Hi Vinay,
>
>> We were skipping when min_softlimit was equal to RPn. We need to apply
>> it rergardless as efficient frequency will push the SLPC min to RPe.
>
> regardless
>
>> This will break scenarios where user sets a min softlimit < RPe before
>> reset and then performs a GT reset.
>
> Can you explain the reason for the patch clearly in terms of variables in
> the code, what variable has what value and what is the bug. I am not
> following from the above description.
>
> Thanks.
> --
> Ashutosh
>
>
>>
>> Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
>>
>> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar at intel.com>
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
>> index 01b75529311c..ee9f83af7cf6 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
>> @@ -606,7 +606,7 @@ static int slpc_set_softlimits(struct intel_guc_slpc *slpc)
>> if (unlikely(ret))
>> return ret;
>> slpc_to_gt(slpc)->defaults.min_freq = slpc->min_freq_softlimit;
>> - } else if (slpc->min_freq_softlimit != slpc->min_freq) {
>> + } else {
>> return intel_guc_slpc_set_min_freq(slpc,
>> slpc->min_freq_softlimit);
>> }
>> --
>> 2.38.1
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 Jun 2023 03:06:15 +0000
> From: "Ma, Yongwei" <yongwei.ma at intel.com>
> To: "Christopherson,, Sean" <seanjc at google.com>, Paolo Bonzini
> <pbonzini at redhat.com>, Zhenyu Wang <zhenyuw at linux.intel.com>, "Wang,
> Zhi A" <zhi.a.wang at intel.com>
> Cc: "kvm at vger.kernel.org" <kvm at vger.kernel.org>,
> "intel-gvt-dev at lists.freedesktop.org"
> <intel-gvt-dev at lists.freedesktop.org>,
> "intel-gfx at lists.freedesktop.org" <intel-gfx at lists.freedesktop.org>,
> "linux-kernel at vger.kernel.org" <linux-kernel at vger.kernel.org>, "Zhao,
> Yan Y" <yan.y.zhao at intel.com>, Ben Gardon <bgardon at google.com>, "Ma,
> Yongwei" <yongwei.ma at intel.com>
> Subject: Re: [Intel-gfx] [PATCH v3 00/28] drm/i915/gvt: KVM: KVMGT
> fixes and page-track cleanups
> Message-ID:
> <BL1PR11MB53686A129ABEC1725EFD5FAE895AA at BL1PR11MB5368.namprd11.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
>> Fix a variety of found-by-inspection bugs in KVMGT, and overhaul KVM's
>> page-track APIs to provide a leaner and cleaner interface. The motivation for
>> this series is to (significantly) reduce the number of KVM APIs that KVMGT
>> uses, with a long-term goal of making all kvm_host.h headers KVM-internal.
>>
>> As always for this series, the KVMGT changes are compile tested only.
>>
>> Based on "git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-6.4-1".
>>
>> v3:
>> - Collect reviewed/tested tags (I apologize if I missed any, I manually
>> gathered them this time due to a goof in my workflow). [Yan]
>> - Drop check on max KVM paging size from KVMGT. [Yan]
>> - Drop the explicit change on THP pages, and instead validate that the
>> pfns (not struct page pointers) are contiguous. [Yan]
>> - Fix buggy intel_gvt_dma_map_guest_page() usage by eliminating a helper
>> for shadowing 2MiB GTT entries. [Yan]
>> - Move kvm_arch_flush_shadow_{all,memslot}() to mmu.c instead of
>> exposing
>> kvm_mmu_zap_all_fast() outside of mmu.c. [Yan]
>> - Fix an alignment goof in hlist_for_each_entry_srcu() usage. [Yan]
>> - Wrap full definition of external page track structures with
>> CONFIG_KVM_EXTERNAL_WRITE_TRACKING. [Yan]
>>
>> v2:
>> - https://lore.kernel.org/all/20230311002258.852397-1-seanjc@google.com
>> - Reuse vgpu_lock to protect gfn hash instead of introducing a new (and
>> buggy) mutext. [Yan]
>> - Remove a spurious return from kvm_page_track_init(). [Yan]
>> - Take @kvm directly in the inner __kvm_page_track_write(). [Yan]
>> - Delete the gfn sanity check that relies on kvm_is_visible_gfn() instead
>> of providing a dedicated interface. [Yan]
>>
>> v1: https://lore.kernel.org/lkml/20221223005739.1295925-1-
>> seanjc at google.com
>>
>> Sean Christopherson (24):
>> drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page"
>> drm/i915/gvt: Verify hugepages are contiguous in physical address
>> space
>> drm/i915/gvt: Put the page reference obtained by KVM's gfn_to_pfn()
>> drm/i915/gvt: Explicitly check that vGPU is attached before shadowing
>> drm/i915/gvt: Error out on an attempt to shadowing an unknown GTT
>> entry type
>> drm/i915/gvt: Don't rely on KVM's gfn_to_pfn() to query possible 2M
>> GTT
>> drm/i915/gvt: Use an "unsigned long" to iterate over memslot gfns
>> drm/i915/gvt: Drop unused helper intel_vgpu_reset_gtt()
>> drm/i915/gvt: Protect gfn hash table with vgpu_lock
>> KVM: x86/mmu: Move kvm_arch_flush_shadow_{all,memslot}() to mmu.c
>> KVM: x86/mmu: Don't rely on page-track mechanism to flush on memslot
>> change
>> KVM: x86/mmu: Don't bounce through page-track mechanism for guest
>> PTEs
>> KVM: drm/i915/gvt: Drop @vcpu from KVM's ->track_write() hook
>> KVM: x86: Reject memslot MOVE operations if KVMGT is attached
>> drm/i915/gvt: Don't bother removing write-protection on to-be-deleted
>> slot
>> KVM: x86/mmu: Move KVM-only page-track declarations to internal header
>> KVM: x86/mmu: Use page-track notifiers iff there are external users
>> KVM: x86/mmu: Drop infrastructure for multiple page-track modes
>> KVM: x86/mmu: Rename page-track APIs to reflect the new reality
>> KVM: x86/mmu: Assert that correct locks are held for page
>> write-tracking
>> KVM: x86/mmu: Bug the VM if write-tracking is used but not enabled
>> KVM: x86/mmu: Drop @slot param from exported/external page-track APIs
>> KVM: x86/mmu: Handle KVM bookkeeping in page-track APIs, not callers
>> drm/i915/gvt: Drop final dependencies on KVM internal details
>>
>> Yan Zhao (4):
>> drm/i915/gvt: remove interface intel_gvt_is_valid_gfn
>> KVM: x86: Add a new page-track hook to handle memslot deletion
>> drm/i915/gvt: switch from ->track_flush_slot() to
>> ->track_remove_region()
>> KVM: x86: Remove the unused page-track hook track_flush_slot()
>>
>> arch/x86/include/asm/kvm_host.h | 16 +-
>> arch/x86/include/asm/kvm_page_track.h | 73 +++-----
>> arch/x86/kvm/mmu.h | 2 +
>> arch/x86/kvm/mmu/mmu.c | 51 +++--
>> arch/x86/kvm/mmu/page_track.c | 256 +++++++++++++-------------
>> arch/x86/kvm/mmu/page_track.h | 58 ++++++
>> arch/x86/kvm/x86.c | 22 +--
>> drivers/gpu/drm/i915/gvt/gtt.c | 102 ++--------
>> drivers/gpu/drm/i915/gvt/gtt.h | 1 -
>> drivers/gpu/drm/i915/gvt/gvt.h | 3 +-
>> drivers/gpu/drm/i915/gvt/kvmgt.c | 117 +++++-------
>> drivers/gpu/drm/i915/gvt/page_track.c | 10 +-
>> 12 files changed, 320 insertions(+), 391 deletions(-) create mode 100644
>> arch/x86/kvm/mmu/page_track.h
>>
>>
>> base-commit: b3c98052d46948a8d65d2778c7f306ff38366aac
>> --
>> 2.40.1.606.ga4b1b128d6-goog
> Verified GVT-g on Intel platform host Core(TM) i7-8559U CPU @ 2.70GHz
> + Ubuntu22.04 LTS.
>
> Both Linux Ubuntu 22.04 VM and Windows10 VM could boot up successfully.
> 3D benchmark GLmark2 can run in the guest VM.
>
> Tested-by: Yongwei Ma <yongwei.ma at intel.com>
>
> Best Regards,
> Yongwei Ma
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 14 Jun 2023 03:24:00 +0000
> From: "Liu, Yi L" <yi.l.liu at intel.com>
> To: Alex Williamson <alex.williamson at redhat.com>, Jason Gunthorpe
> <jgg at nvidia.com>
> Cc: "Tian, Kevin" <kevin.tian at intel.com>, "joro at 8bytes.org"
> <joro at 8bytes.org>, "robin.murphy at arm.com" <robin.murphy at arm.com>,
> "cohuck at redhat.com" <cohuck at redhat.com>, "eric.auger at redhat.com"
> <eric.auger at redhat.com>, "nicolinc at nvidia.com" <nicolinc at nvidia.com>,
> "kvm at vger.kernel.org" <kvm at vger.kernel.org>, "mjrosato at linux.ibm.com"
> <mjrosato at linux.ibm.com>, "chao.p.peng at linux.intel.com"
> <chao.p.peng at linux.intel.com>, "yi.y.sun at linux.intel.com"
> <yi.y.sun at linux.intel.com>, "peterx at redhat.com" <peterx at redhat.com>,
> "jasowang at redhat.com" <jasowang at redhat.com>,
> "shameerali.kolothum.thodi at huawei.com"
> <shameerali.kolothum.thodi at huawei.com>, "lulu at redhat.com"
> <lulu at redhat.com>, "suravee.suthikulpanit at amd.com"
> <suravee.suthikulpanit at amd.com>, "intel-gvt-dev at lists.freedesktop.org"
> <intel-gvt-dev at lists.freedesktop.org>,
> "intel-gfx at lists.freedesktop.org" <intel-gfx at lists.freedesktop.org>,
> "linux-s390 at vger.kernel.org" <linux-s390 at vger.kernel.org>, "Hao,
> Xudong" <xudong.hao at intel.com>, "Zhao, Yan Y" <yan.y.zhao at intel.com>,
> "Xu, Terrence" <terrence.xu at intel.com>, "Jiang, Yanting"
> <yanting.jiang at intel.com>, "Duan, Zhenzhong"
> <zhenzhong.duan at intel.com>, "clegoate at redhat.com"
> <clegoate at redhat.com>
> Subject: Re: [Intel-gfx] [PATCH v12 21/24] vfio: Determine noiommu
> device in __vfio_register_dev()
> Message-ID:
> <DS0PR11MB7529F2D5EF95E9E1D63C9264C35AA at DS0PR11MB7529.namprd11.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
>> From: Alex Williamson <alex.williamson at redhat.com>
>> Sent: Wednesday, June 14, 2023 4:11 AM
>>
>> On Tue, 13 Jun 2023 14:35:09 -0300
>> Jason Gunthorpe <jgg at nvidia.com> wrote:
>>
>>> On Tue, Jun 13, 2023 at 11:15:11AM -0600, Alex Williamson wrote:
>>>> [Sorry for breaking threading, replying to my own message id with reply
>>>> content from Yi since the Cc list got broken]
>>>
>>> Yikes it is really busted, I think I fixed it?
>>>
>>>> If we renamed your function above to vfio_device_has_iommu_group(),
>>>> couldn't we just wrap device_add like below instead to not have cdev
>>>> setup for a noiommu device, generate an error for a physical device w/o
>>>> IOMMU backing, and otherwise setup the cdev device?
>>>>
>>>> static inline int vfio_device_add(struct vfio_device *device, enum vfio_group_type
>> type)
>>>> {
>>>> #if IS_ENABLED(CONFIG_VFIO_GROUP)
>>>> if (device->group->type == VFIO_NO_IOMMU)
>>>> return device_add(&device->device);
>>>
>>> vfio_device_is_noiommu() embeds the IS_ENABLED
>>
>> But patch 23/ makes the definition of struct vfio_group conditional on
>> CONFIG_VFIO_GROUP, so while CONFIG_VFIO_NOIOMMU depends on
>> CONFIG_VFIO_GROUP and the result could be determined, I think the
>> compiler is still unhappy about the undefined reference. We'd need a
>> !CONFIG_VFIO_GROUP stub for the function.
>>
>>>> #else
>>>> if (type == VFIO_IOMMU && !vfio_device_has_iommu_group(device))
>>>> return -EINVAL;
>>>> #endif
>>>
>>> The require test is this from the group code:
>>>
>>> if (!device_iommu_capable(dev, IOMMU_CAP_CACHE_COHERENCY)) {
>>>
>>> We could lift it out of the group code and call it from vfio_main.c like:
>>>
>>> if (type == VFIO_IOMMU && !vfio_device_is_noiommu(vdev)
>> && !device_iommu_capable(dev,
>>> IOMMU_CAP_CACHE_COHERENCY))
>>> FAIL
>>
>> Ack. Thanks,
>
> So, what I got is:
>
> 1) Add bellow check in __vfio_register_dev() to fail the physical devices that
> don't have IOMMU protection.
>
> /*
> * noiommu device is a special type supported by the group interface.
> * Such type represents the physical devices that are not iommu backed.
> */
> if (type == VFIO_IOMMU && !vfio_device_is_noiommu(device)) &&
> !vfio_device_has_iommu_group(device))
> return -EINVAL; //or maybe -EOPNOTSUPP?
>
> Nit: require a vfio_device_is_noiommu() stub which returns false for
> the VFIO_GROUP unset case.
>
> 2) Have below functions to add device
>
> #if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)
> static inline int vfio_device_add(struct vfio_device *device)
> {
> if (vfio_device_is_noiommu(device))
> return device_add(&device->device);
> vfio_init_device_cdev(device);
> return cdev_device_add(&device->cdev, &device->device);
> }
>
> static inline void vfio_device_del(struct vfio_device *device)
> {
> if (vfio_device_is_noiommu(device))
> return device_del(&device->device);
> cdev_device_del(&device->cdev, &device->device);
> }
> #else
> blabla
> #endif
>
> Regards,
> Yi Liu
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
> ------------------------------
>
> End of Intel-gfx Digest, Vol 185, Issue 285
> *******************************************
More information about the Intel-gfx
mailing list