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
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 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 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.
Didn't we discuss
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
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 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
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 the
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
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 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 it
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
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
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
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 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
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 <pbonz...@redhat.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 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 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 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 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 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: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 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 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 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))
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
; 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(
32 matches
Mail list logo
