; 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 insertions(
On 3/29/23 18:43, Christian König wrote:
3) other uses of kmap() must switch to MMU-notifier protection.
I would rather suggest to return the page additionally to the pfn from
hva_to_pfn() when the function was able to grab a reference to it.
When the page is then not available you can't
On 3/29/23 17:29, Christian König wrote:
First, is it a _host_ corruption or a guest corruption/crash? A guest
crash would be KVM doing exactly what it's meant to do: it detects the
non-reserved, non-refcounted page and refuses to map it into the guest.
Yes I think that this is what happens.
On 3/29/23 16:28, Paolo Bonzini wrote:
On 3/29/23 15:54, Christian König wrote:
KVM tries to grab references to pages in VMAs marked with VM_PFNMAP.
This is illegal and can cause data corruption with TTM pages because
only some of them are actually reference counted.
After some other offlist
On 3/29/23 15:54, Christian König wrote:
KVM tries to grab references to pages in VMAs marked with VM_PFNMAP.
This is illegal and can cause data corruption with TTM pages because
only some of them are actually reference counted.
I think that you are referring to this:
/* Don't set the
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
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
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
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
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
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))
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
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
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
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
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
On 10/05/21 19:57, Sean Christopherson wrote:
+Paolo
On Mon, May 10, 2021, Jason Gunthorpe wrote:
On Mon, May 10, 2021 at 04:55:39PM +0200, Daniel Vetter wrote:
yeah vfio is still broken for the case I care about. I think there's
also some questions open still about whether kvm really uses
r the new follow_pte()
function.
Cc: 3...@google.com
Cc: Jann Horn
Cc: Paolo Bonzini
Cc: Jason Gunthorpe
Cc: Cornelia Huck
Cc: Peter Xu
Cc: Alex Williamson
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc:
On 24/03/21 13:52, Jason Gunthorpe wrote:
I think this is the right thing to do.
Alex is working on fixing VFIO and while kvm is still racy using
follow pte, I think they are working on it too?
Yeah, or at least we have a plan.
Paolo
___
dri-devel
On 20/11/20 16:44, Daniel Vetter wrote:
It's a bit of a pity, it's making an API more complex (the point of
gfn_to_pfn_memslot vs gfn_to_pfn is exactly that you don't need a
"struct kvm*" and it's clear that you've already done the lookup into
that struct kvm.
Yeah I noticed that, I think
of
gfn_to_pfn_memslot vs gfn_to_pfn is exactly that you don't need a
"struct kvm*" and it's clear that you've already done the lookup into
that struct kvm.
But it's not a big deal, and the rationale at least makes sense. So,
Acked-by: Paolo Bonzi
On 21/04/20 15:57, Emanuele Giuseppe Esposito wrote:
> - inode = debugfs_get_inode(dentry->d_sb);
You're not removing debugfs_get_inode so I think you're going to get a
warning (same in tracefs)?
You can wait a few more days for reviews and/or Acked-bys (especially
for patches 6 and 7) and
On 20/04/20 16:28, Greg Kroah-Hartman wrote:
>> I assume you meant a new file. These new functions are used only by a few
>> filesystems, and I didn't want to include them in vmlinux unconditionally,
>> so I introduced simplefs.c and CONFIG_SIMPLEFS instead of extending libfs.c.
>> In this way
On 14/02/20 23:03, Sean Christopherson wrote:
>> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote:
>>> AFAICT, it is currently allowed on ARM (verified) and AMD (not
>>> verified, but svm_get_mt_mask returns 0 which supposedly means the NPT
>>> does not restrict what the guest PAT can do). This
On 13/02/20 23:18, Chia-I Wu wrote:
>
> The bug you mentioned was probably this one
>
> https://bugzilla.kernel.org/show_bug.cgi?id=104091
Yes, indeed.
> From what I can tell, the commit allowed the guests to create cached
> mappings to MMIO regions and caused MCEs. That is different than
On 13/02/20 22:30, Chia-I Wu wrote:
> Better reflect the structure of the code and metion why we could not
> always honor the guest.
>
> Signed-off-by: Chia-I Wu
> Cc: Gurchetan Singh
> Cc: Gerd Hoffmann
> ---
> arch/x86/kvm/vmx/vmx.c | 27 +--
> 1 file changed, 17
On 13/02/20 22:30, Chia-I Wu wrote:
> Hi,
>
> Host GPU drivers like to give userspace WC mapping. When the userspace makes
> the mapping available to a guest, it also tells the guest to create a WC
> mapping. However, even when the guest kernel picks the correct memory type,
> it gets ignored
On 05/12/19 12:27, Dmitry Vyukov wrote:
> Oh, you mean the final bisection crash. Indeed it contains a kvm frame
> and it turns out to be a bug in syzkaller code that indeed
> misattributed it to kvm instead of netfilter.
> Should be fixed now, you may read the commit message for details:
>
On 05/12/19 11:31, Dmitry Vyukov wrote:
>> Ah, and because the machine is a KVM guest, kvm_wait appears in a lot of
>> backtrace and I get to share syzkaller's joy every time. :)
> I don't see any mention of "kvm" in the crash report.
It's there in the stack trace, not sure if this is what
On 05/12/19 11:16, Dmitry Vyukov wrote:
> On Thu, Dec 5, 2019 at 11:13 AM Paolo Bonzini wrote:
>>
>> On 04/12/19 22:41, syzbot wrote:
>>> syzbot has bisected this bug to:
>>>
>>> commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
>>> Author: Russel
On 04/12/19 22:41, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 2de50e9674fc4ca3c6174b04477f69eb26b4ee31
> Author: Russell Currey
> Date: Mon Feb 8 04:08:20 2016 +
>
> powerpc/powernv: Remove support for p5ioc2
>
> bisection log:
On 30/05/19 01:23, Mauro Carvalho Chehab wrote:
> Sphinx doesn't like orphan documents:
>
> Documentation/accelerators/ocxl.rst: WARNING: document isn't included in
> any toctree
> Documentation/arm/stm32/overview.rst: WARNING: document isn't included in
> any toctree
>
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
>>>
>>&
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;
>
>
On 22/11/2016 19:54, Eric Blake wrote:
>>> >> DRM DRIVER FOR BOCHS VIRTUAL GPU
>>> >> M: Gerd Hoffmann
>>> >> -S: Odd Fixes
>>> >> +L: qemu-devel at nongnu.org
>> >
>> > qemu-devel list already has very high traffic - not sure whether it
>> > makes much sense to route even
On 31/10/2016 14:48, Lorenzo Stoakes wrote:
> On Mon, Oct 31, 2016 at 12:45:36PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 31/10/2016 11:02, Lorenzo Stoakes wrote:
>>> - *
>>> - * get_user_pages should be phased out in favor of
>>> - * get_user_pages
On 31/10/2016 11:02, Lorenzo Stoakes wrote:
> - *
> - * get_user_pages should be phased out in favor of
> - * get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
> - * should use get_user_pages because it cannot pass
> - * FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.
This comment
e {
> + 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
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 t
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
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
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, xe
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
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
44 matches
Mail list logo
