All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: intel-gfx@lists.freedesktop.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
Date: Wed, 24 Sep 2014 23:18:10 +0200	[thread overview]
Message-ID: <54233512.6040409@redhat.com> (raw)
In-Reply-To: <1411592242.24563.177.camel@ul30vt.home>

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 guest address space which is an mmap
> to the host address space, using /dev/mem for now, but hopefully the
> vfio file descriptor in the future (I should be careful what I hope
> for).

Yeah, I remember discussing that with Andrew on IRC.  So he did
implement that idea.

> The opregion is pretty trivial because the write is to the IGD itself.
> The others are to the host bridge, so we need to figure out what sort of
> abstraction makes sense to get that back into vfio code.

Do we have to support all chipsets?  IIUC the more recent devices need
fewer and fewer "backdoors".

Paolo

> Perhaps vfio creates all the memory regions and registers them into an
> igd service and the host bridge can make calls like:
> 
> gtt = igd_get_gtt_mr();
> 
> which returns NULL and nothing happens or the registered MemoryRegion
> and the host bridge places it into the address space.  Thanks,

WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: intel-gfx@lists.freedesktop.org,
	Andrew Barnes <umbramalison@gmail.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO
Date: Wed, 24 Sep 2014 23:18:10 +0200	[thread overview]
Message-ID: <54233512.6040409@redhat.com> (raw)
In-Reply-To: <1411592242.24563.177.camel@ul30vt.home>

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 guest address space which is an mmap
> to the host address space, using /dev/mem for now, but hopefully the
> vfio file descriptor in the future (I should be careful what I hope
> for).

Yeah, I remember discussing that with Andrew on IRC.  So he did
implement that idea.

> The opregion is pretty trivial because the write is to the IGD itself.
> The others are to the host bridge, so we need to figure out what sort of
> abstraction makes sense to get that back into vfio code.

Do we have to support all chipsets?  IIUC the more recent devices need
fewer and fewer "backdoors".

Paolo

> Perhaps vfio creates all the memory regions and registers them into an
> igd service and the host bridge can make calls like:
> 
> gtt = igd_get_gtt_mr();
> 
> which returns NULL and nothing happens or the registered MemoryRegion
> and the host bridge places it into the address space.  Thanks,

  reply	other threads:[~2014-09-24 21:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24 13:20 [IGDVFIO] [PATCH 3/8] RFC and help completing: Intel IGD Direct Assignment with VFIO Andrew Barnes
2014-09-24 13:20 ` [Qemu-devel] " Andrew Barnes
2014-09-24 19:47 ` Alex Williamson
2014-09-24 19:47   ` [Qemu-devel] " Alex Williamson
2014-09-24 20:31   ` Paolo Bonzini
2014-09-24 20:31     ` [Qemu-devel] " Paolo Bonzini
2014-09-24 20:57     ` Alex Williamson
2014-09-24 20:57       ` Alex Williamson
2014-09-24 21:18       ` Paolo Bonzini [this message]
2014-09-24 21:18         ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54233512.6040409@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.