Re: [PATCH v2 2/4] eventfd: simplify eventfd_signal()

2024-02-07 Thread Paolo Bonzini
n > keeping that additional argument. > > Signed-off-by: Christian Brauner > --- > arch/x86/kvm/hyperv.c | 2 +- > arch/x86/kvm/xen.c| 2 +- > virt/kvm/eventfd.c| 4 ++-- > 30 files changed, 60 insert

Re: [Intel-gfx] [PATCH v2 1/5] KVM: do not allow mapping valid but non-refcounted pages

2021-06-25 Thread Paolo Bonzini
On 25/06/21 09:58, Christian Borntraeger wrote: On 25.06.21 09:36, David Stevens wrote: From: Nicholas Piggin It's possible to create a region which maps valid but non-refcounted pages (e.g., tail pages of non-compound higher order allocations). These host pages can then be returned by gfn_t

Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU

2021-06-24 Thread Paolo Bonzini
On 24/06/21 14:57, Nicholas Piggin wrote: KVM: Fix page ref underflow for regions with valid but non-refcounted pages It doesn't really fix the underflow, it disallows mapping them in the first place. Since in principle things can break, I'd rather be explicit, so let's go with "KVM: do not

Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU

2021-06-24 Thread Paolo Bonzini
On 24/06/21 13:42, Nicholas Piggin wrote: Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm: Excerpts from David Stevens's message of June 24, 2021 1:57 pm: KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using follow_pte in gfn_to_pfn. However, the resolved pfn

Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU

2021-06-24 Thread Paolo Bonzini
On 24/06/21 13:42, Nicholas Piggin wrote: +static int kvm_try_get_pfn(kvm_pfn_t pfn) +{ + if (kvm_is_reserved_pfn(pfn)) + return 1; So !pfn_valid would always return true. Yeah, this should work and is certainly appealing! Paolo + return get_page_unless_zero(pfn

Re: [Intel-gfx] [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn

2021-06-24 Thread Paolo Bonzini
On 24/06/21 12:17, Nicholas Piggin wrote: If all callers were updated that is one thing, but from the changelog it sounds like that would not happen and there would be some gfn_to_pfn users left over. But yes in the end you would either need to make gfn_to_pfn never return a page found via follo

Re: [Intel-gfx] [PATCH 3/6] KVM: x86/mmu: avoid struct page in MMU

2021-06-24 Thread Paolo Bonzini
On 24/06/21 12:06, Marc Zyngier wrote: On Thu, 24 Jun 2021 09:58:00 +0100, Nicholas Piggin wrote: Excerpts from David Stevens's message of June 24, 2021 1:57 pm: From: David Stevens out_unlock: if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa)) read_unlock(&v

Re: [Intel-gfx] [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn

2021-06-24 Thread Paolo Bonzini
On 24/06/21 11:57, Nicholas Piggin wrote: Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so it's a good idea to move the short name to the common case and the ugly kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not sure there should be any kvm_pfn_page_

Re: [Intel-gfx] [PATCH 1/6] KVM: x86/mmu: release audited pfns

2021-06-24 Thread Paolo Bonzini
On 24/06/21 10:43, Nicholas Piggin wrote: Excerpts from David Stevens's message of June 24, 2021 1:57 pm: From: David Stevens Changelog? This looks like a bug, should it have a Fixes: tag? Probably has been there forever... The best way to fix the bug would be to nuke mmu_audit.c, which I'

Re: [Intel-gfx] [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn

2021-06-24 Thread Paolo Bonzini
On 24/06/21 10:52, Nicholas Piggin wrote: For now, wrap all calls to gfn_to_pfn functions in the new helper function. Callers which don't need the page struct will be updated in follow-up patches. Hmm. You mean callers that do need the page will be updated? Normally if there will be leftover use

Re: [Intel-gfx] [PATCH 3/6] KVM: x86/mmu: avoid struct page in MMU

2021-06-24 Thread Paolo Bonzini
On 24/06/21 05:57, David Stevens wrote: static int __direct_map(struct kvm_vcpu *vcpu, gpa_t gpa, u32 error_code, - int map_writable, int max_level, kvm_pfn_t pfn, + int map_writable, int max_level, + const struct kvm_pfn_page *p

Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU

2021-06-23 Thread Paolo Bonzini
On 24/06/21 05:57, David Stevens wrote: KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using follow_pte in gfn_to_pfn. However, the resolved pfns may not have assoicated struct pages, so they should not be passed to pfn_to_page. This series removes such calls from the x86 and a

[Intel-gfx] [FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock

2021-02-08 Thread Paolo Bonzini
Adjust the KVMGT page tracking callbacks. Cc: Zhenyu Wang Cc: Zhi Wang Cc: intel-gvt-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Paolo Bonzini --- drivers/gpu/drm/i915/gvt/kvmgt.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a

Re: [Intel-gfx] Possible use_mm() mis-uses

2018-08-23 Thread Paolo Bonzini
On 23/08/2018 08:07, Zhenyu Wang wrote: > On 2018.08.22 20:20:46 +0200, Paolo Bonzini wrote: >> On 22/08/2018 18:44, Linus Torvalds wrote: >>> An example of something that *isn't* right, is the i915 kvm interface, >>> which does >>> >>>

Re: [Intel-gfx] Possible use_mm() mis-uses

2018-08-22 Thread Paolo Bonzini
On 22/08/2018 18:44, Linus Torvalds wrote: > An example of something that *isn't* right, is the i915 kvm interface, > which does > > use_mm(kvm->mm); > > on an mm that was initialized in virt/kvm/kvm_main.c using > > mmgrab(current->mm); > kvm->mm = current->mm; > > whic

Re: [Intel-gfx] [GIT PULL] kvm/page_track changes for i915 KVMGT

2016-11-09 Thread Paolo Bonzini
On 09/11/2016 16:15, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 03:25:19PM +0100, Paolo Bonzini wrote: >> Daniel, >> >> The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: >> >> kvm: x86: Check memopp before dereference (CVE-20

[Intel-gfx] [GIT PULL] kvm/page_track changes for i915 KVMGT

2016-11-09 Thread Paolo Bonzini
Daniel, The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 21:31:53 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt for you to fetch

Re: [Intel-gfx] [PATCH 0/2] extend page_track for external usage

2016-11-09 Thread Paolo Bonzini
On 09/11/2016 03:03, Zhenyu Wang wrote: > On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote: Paolo, for this case, do you think it's feasible we pick them through drm/i915 merge path? As currently initial KVMGT patch sets require these exported symbols, that's why I ask how we shou

Re: [Intel-gfx] [PATCH 02/10] mm: remove write/force parameters from __get_user_pages_unlocked()

2016-10-12 Thread Paolo Bonzini
} else > + } else { > + unsigned int flags = FOLL_TOUCH | FOLL_HWPOISON; > + > + if (write_fault) > + flags |= FOLL_WRITE; > + > npages = __get_user_pages_unlocked(current, current->mm, addr, > 1, > -write_fault, 0, page, > -FOLL_TOUCH|FOLL_HWPOISON); > +page, flags); > + } > if (npages != 1) > return npages; > > Acked-by: Paolo Bonzini ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

2015-11-19 Thread Paolo Bonzini
On 19/11/2015 16:32, Stefano Stabellini wrote: > > In addition to Kevin's replies, I have a high-level question: can VFIO > > be used by QEMU for both KVM and Xen? > > No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU > is owned by Xen. I don't think QEMU command line compa

Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

2015-11-19 Thread Paolo Bonzini
On 19/11/2015 09:40, Gerd Hoffmann wrote: >> > But this code should be >> > minor to be maintained in libvirt. > As far I know libvirt only needs to discover those devices. If they > look like sr/iov devices in sysfs this might work without any changes to > libvirt. I don't think they will look

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2014-12-10 Thread Paolo Bonzini
On 11/12/2014 01:33, Tian, Kevin wrote: > My point is that KVMGT doesn't introduce new requirements as what's > required in IGD passthrough case, because all the hacks you see now > is to satisfy guest graphics driver's expectation. I haven't follow up the > KVM IGD passthrough progress, but if i

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2014-12-10 Thread Paolo Bonzini
On 09/12/2014 03:49, Tian, Kevin wrote: > - Now we have XenGT/KVMGT separately maintained, and KVMGT lags > behind XenGT regarding to features and qualities. Likely you'll continue > see stale code (like Xen inst decoder) for some time. In the future we > plan to maintain a single kernel repo for

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2014-12-05 Thread Paolo Bonzini
On 05/12/2014 09:50, Gerd Hoffmann wrote: > A few comments on the kernel stuff (brief look so far, also > compile-tested only, intel gfx on my test machine is too old). > > * Noticed the kernel bits don't even compile when configured as >module. Everything (vgt, i915, kvm) must be compiled

Re: [Intel-gfx] [Qemu-devel] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO

2014-09-24 Thread Paolo Bonzini
Il 24/09/2014 22:57, Alex Williamson ha scritto: > Right, that's the physical mapping, Andy's patches are mimicking that > behavior virtually. Seabios reserves memory, creates e820 entries, and > "maps" the hardware by writing to these registers. That triggers QEMU > to adjust the MemoryRegion in

Re: [Intel-gfx] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO

2014-09-24 Thread Paolo Bonzini
Il 24/09/2014 21:47, Alex Williamson ha scritto: > So the opregion is mapped by a config write on the IGD device itself and > the other 3 regions, that we know about so far, are mapped via writes to > the host bridge. AFAIU the opregion is mapped by the (host) BIOS, that writes the address to a we

Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

2014-07-29 Thread Paolo Bonzini
Il 29/07/2014 08:59, Chen, Tiejun ha scritto: >> >> (see https://lkml.org/lkml/2014/6/19/121) >>> "gpu:drm:i915:intel_detect_pch: back to check devfn instead of check >>> class >>> type". Because Windows always use this way, so I think this point >>> should be >>> same between Linux and Windows. >>

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

2014-07-07 Thread Paolo Bonzini
Il 07/07/2014 19:54, Daniel Vetter ha scritto: On Mon, Jul 07, 2014 at 04:57:45PM +0200, Paolo Bonzini wrote: Il 07/07/2014 16:49, Daniel Vetter ha scritto: So the correct fix to forward intel gpus to guests is indeed to somehow fake the pch pci ids since the driver really needs them. Gross

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

2014-07-07 Thread Paolo Bonzini
Il 07/07/2014 16:49, Daniel Vetter ha scritto: So the correct fix to forward intel gpus to guests is indeed to somehow fake the pch pci ids since the driver really needs them. Gross design, but that's how the hardware works. A way that could work for virtualization is this: if you find the card

Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

2014-07-03 Thread Paolo Bonzini
Il 03/07/2014 21:09, Jesse Barnes ha scritto: Practically speaking, we could probably assume specific CPU/PCH combos, as I don't think they're generally mixed across generations, though SNB and IVB did have compatible sockets, so there is the possibility of mixing CPT and PPT PCHs, but those are

Re: [Intel-gfx] ResettRe: [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support

2014-07-02 Thread Paolo Bonzini
Il 02/07/2014 18:23, Konrad Rzeszutek Wilk ha scritto: diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 651e65e..03f2829 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_devi

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

2014-06-30 Thread Paolo Bonzini
Il 30/06/2014 05:13, Chen, Tiejun ha scritto: After I discuss internal, we think even we just set the real vendor/device ids to this ISA bridge at 00:1f.0, guest firmware should still work well with these pair of real vendor/device ids. So if you think something would conflict or be broken, coul

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

2014-06-25 Thread Paolo Bonzini
Il 25/06/2014 09:34, Chen, Tiejun ha scritto: On 2014/6/25 14:48, Paolo Bonzini wrote: Second problem. Your IGD passthrough code currently works with QEMU's PIIX4-based machine. But what happens if you try to extend it, so that Yes, current xen machine, xenpv, is based on pii4, and a

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

2014-06-24 Thread Paolo Bonzini
Il 22/06/2014 10:25, Chen, Tiejun ha scritto: In qemu-upstream, as you commented we can't create this as a ISA class type explicitly. Note I didn't say that QEMU doesn't like having two ISA bridges. I commented that the firmware will see two ISA bridges and will try to initialize both of them

Re: [Intel-gfx] [RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

2014-06-20 Thread Paolo Bonzini
Il 19/06/2014 11:53, Tiejun Chen ha scritto: so this mean that isa bridge is still represented with Dev31:Func0 like the native OS. Furthermore, currently we're pushing VGA passthrough support into qemu upstream, and with some discussion, we wouldn't set the bridge class type and just expose this