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
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
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 pfn
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
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
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
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_
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'
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
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
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
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
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;
>
> whic
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
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
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
} 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
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
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
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
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
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
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
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
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.
>>
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
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
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
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
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
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
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
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
35 matches
Mail list logo