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@xxxxxxxxxxxxxxxxxxxxx wrote: > > Send Intel-gfx mailing list submissions to > intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxx > > You can reach the person managing the list at > intel-gfx-owner@xxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxx> > To: Vinay Belgaumkar <vinay.belgaumkar@xxxxxxxxx> > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx, dri-devel@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [PATCH] drm/i915/guc/slpc: Apply min > softlimit correctly > Message-ID: <87zg52ye3d.wl-ashutosh.dixit@xxxxxxxxx> > 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@xxxxxxxxx> >> --- >> 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@xxxxxxxxx> > To: "Christopherson,, Sean" <seanjc@xxxxxxxxxx>, Paolo Bonzini > <pbonzini@xxxxxxxxxx>, Zhenyu Wang <zhenyuw@xxxxxxxxxxxxxxx>, "Wang, > Zhi A" <zhi.a.wang@xxxxxxxxx> > Cc: "kvm@xxxxxxxxxxxxxxx" <kvm@xxxxxxxxxxxxxxx>, > "intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx" > <intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx>, > "intel-gfx@xxxxxxxxxxxxxxxxxxxxx" <intel-gfx@xxxxxxxxxxxxxxxxxxxxx>, > "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "Zhao, > Yan Y" <yan.y.zhao@xxxxxxxxx>, Ben Gardon <bgardon@xxxxxxxxxx>, "Ma, > Yongwei" <yongwei.ma@xxxxxxxxx> > Subject: Re: [PATCH v3 00/28] drm/i915/gvt: KVM: KVMGT > fixes and page-track cleanups > Message-ID: > <BL1PR11MB53686A129ABEC1725EFD5FAE895AA@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxx >> - 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@xxxxxxxxxx >> >> 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@xxxxxxxxx> > > Best Regards, > Yongwei Ma > > > ------------------------------ > > Message: 3 > Date: Wed, 14 Jun 2023 03:24:00 +0000 > From: "Liu, Yi L" <yi.l.liu@xxxxxxxxx> > To: Alex Williamson <alex.williamson@xxxxxxxxxx>, Jason Gunthorpe > <jgg@xxxxxxxxxx> > Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "joro@xxxxxxxxxx" > <joro@xxxxxxxxxx>, "robin.murphy@xxxxxxx" <robin.murphy@xxxxxxx>, > "cohuck@xxxxxxxxxx" <cohuck@xxxxxxxxxx>, "eric.auger@xxxxxxxxxx" > <eric.auger@xxxxxxxxxx>, "nicolinc@xxxxxxxxxx" <nicolinc@xxxxxxxxxx>, > "kvm@xxxxxxxxxxxxxxx" <kvm@xxxxxxxxxxxxxxx>, "mjrosato@xxxxxxxxxxxxx" > <mjrosato@xxxxxxxxxxxxx>, "chao.p.peng@xxxxxxxxxxxxxxx" > <chao.p.peng@xxxxxxxxxxxxxxx>, "yi.y.sun@xxxxxxxxxxxxxxx" > <yi.y.sun@xxxxxxxxxxxxxxx>, "peterx@xxxxxxxxxx" <peterx@xxxxxxxxxx>, > "jasowang@xxxxxxxxxx" <jasowang@xxxxxxxxxx>, > "shameerali.kolothum.thodi@xxxxxxxxxx" > <shameerali.kolothum.thodi@xxxxxxxxxx>, "lulu@xxxxxxxxxx" > <lulu@xxxxxxxxxx>, "suravee.suthikulpanit@xxxxxxx" > <suravee.suthikulpanit@xxxxxxx>, "intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx" > <intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx>, > "intel-gfx@xxxxxxxxxxxxxxxxxxxxx" <intel-gfx@xxxxxxxxxxxxxxxxxxxxx>, > "linux-s390@xxxxxxxxxxxxxxx" <linux-s390@xxxxxxxxxxxxxxx>, "Hao, > Xudong" <xudong.hao@xxxxxxxxx>, "Zhao, Yan Y" <yan.y.zhao@xxxxxxxxx>, > "Xu, Terrence" <terrence.xu@xxxxxxxxx>, "Jiang, Yanting" > <yanting.jiang@xxxxxxxxx>, "Duan, Zhenzhong" > <zhenzhong.duan@xxxxxxxxx>, "clegoate@xxxxxxxxxx" > <clegoate@xxxxxxxxxx> > Subject: Re: [PATCH v12 21/24] vfio: Determine noiommu > device in __vfio_register_dev() > Message-ID: > <DS0PR11MB7529F2D5EF95E9E1D63C9264C35AA@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> > > Content-Type: text/plain; charset="us-ascii" > >> From: Alex Williamson <alex.williamson@xxxxxxxxxx> >> Sent: Wednesday, June 14, 2023 4:11 AM >> >> On Tue, 13 Jun 2023 14:35:09 -0300 >> Jason Gunthorpe <jgg@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > ------------------------------ > > End of Intel-gfx Digest, Vol 185, Issue 285 > *******************************************
