qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
Cc: ehabkost@redhat.com, stefano.stabellini@eu.citrix.com,
	mst@redhat.com, "Kay, Allen M" <allen.m.kay@intel.com>,
	qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthrough
Date: Tue, 9 Feb 2016 10:43:32 -0700	[thread overview]
Message-ID: <20160209104332.775b88f8@t450s.home> (raw)
In-Reply-To: <20160208203235.69088310@t450s.home>


Tiejun's email bounced, so adding Allen for comment.  Host bridge
registers 52h, a4h, and a8h seem to be for versions of IGD prior to
SandyBridge or just wrong.  Even the GMCH (50h) doesn't seem to be
necessary for the VM host bridge, so I'm thinking about dropping all of
these for vfio-based IGD assignment.  Do we know which guest drivers
have specific dependencies on which host bridge and LPC bridge
registers?  It would even be nice to document the standard
registers for future maintainability.  Thanks,

Alex


On Mon, 8 Feb 2016 20:32:35 -0700
Alex Williamson <alex.williamson@redhat.com> wrote:

> On Wed, 15 Jul 2015 13:37:43 +0800
> Tiejun Chen <tiejun.chen@intel.com> wrote:
> 
> > Implement a pci host bridge specific to passthrough. Actually
> > this just inherits the standard one. And we also just expose
> > a minimal real host bridge pci configuration subset.
> > 
> > Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > v10:
> >  
> > * Nothing is changed.
> > 
> > v9:
> >  
> > * Just rebase on the latest.
> > 
> >  hw/pci-host/piix.c   | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  include/hw/i386/pc.h |  2 ++
> >  2 files changed, 84 insertions(+)
> > 
> > diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> > index a203d93..7adf645 100644
> > --- a/hw/pci-host/piix.c
> > +++ b/hw/pci-host/piix.c
> > @@ -734,6 +734,87 @@ static const TypeInfo i440fx_info = {
> >      .class_init    = i440fx_class_init,
> >  };
> >  
> > +/* IGD Passthrough Host Bridge. */
> > +typedef struct {
> > +    uint8_t offset;
> > +    uint8_t len;
> > +} IGDHostInfo;
> > +
> > +/* Here we just expose minimal host bridge offset subset. */
> > +static const IGDHostInfo igd_host_bridge_infos[] = {
> > +    {0x08, 2},  /* revision id */
> > +    {0x2c, 2},  /* sybsystem vendor id */
> > +    {0x2e, 2},  /* sybsystem id */
> > +    {0x50, 2},  /* SNB: processor graphics control register */
> > +    {0x52, 2},  /* processor graphics control register */
> > +    {0xa4, 4},  /* SNB: graphics base of stolen memory */
> > +    {0xa8, 4},  /* SNB: base of GTT stolen memory */
> > +};  
> 
> Hi,
> 
> I'm confused by these last 4 registers, could you please help me
> understand them?
> 
> Offset 0x50 is the GMCH register for SandyBridge and newer processors,
> that makes sense, but I suspect we really want to mask out the GMS
> field to indicate the size of stolen memory is zero?  Is Xen providing
> the VM with direct access to host stolen memory or does it have support
> in the VM BIOS for matching the host address?
> 
> 0x52 is unknown to me, it's listed as reserved for anything since
> SandyBridge, does this date back to chipset-based graphics versus the
> current processor-based graphics?
> 
> The comment on 0xa4 suggests it should be the BDSM regiser, but that's
> at offset 0xb0 for everything since SandyBridge.  0xa4 is the second
> DWORD of the Top Of Memory (TOM) register.
> 
> I'm guessing by the description of 0xa8 that it might be the BGSM
> register, but that's at 0xb4.  0xa8 is the first DWORD of the Top Of
> Upper Usable DRAM (TOUUD).  Neither TOM or TOUUD seem to make any sense
> to expose to the VM, which really makes me wonder if they're actually
> used.
> 
> I'm looking at volume 2 of the processor datasheets here:
> 
> http://www.intel.com/content/www/us/en/processors/core/core-technical-resources.html
> 
> Am I maybe looking in the wrong place?  Thanks for your time,
> 
> Alex
> 

  reply	other threads:[~2016-02-09 17:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-15  5:37 [Qemu-devel] [v10][PATCH 00/10] xen: add Intel IGD passthrough Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 01/10] i440fx: make types configurable at run-time Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 02/10] pc_init1: pass parameters just with types Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthrough Tiejun Chen
2016-02-09  3:32   ` Alex Williamson
2016-02-09 17:43     ` Alex Williamson [this message]
2016-02-09 17:56       ` Paolo Bonzini
2016-02-09 19:47       ` Kay, Allen M
2016-02-09 21:32         ` Alex Williamson
2016-02-10  3:40           ` Kay, Allen M
2016-02-10  6:00             ` Alex Williamson
2016-02-11  2:25               ` Kay, Allen M
2016-02-11  6:07                 ` Alex Williamson
2016-02-15 11:28           ` Gerd Hoffmann
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 04/10] hw/pci-assign: split pci-assign.c Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 05/10] xen, gfx passthrough: basic graphics passthrough support Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 06/10] xen, gfx passthrough: retrieve VGA BIOS to work Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 07/10] igd gfx passthrough: create a isa bridge Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 08/10] xen, gfx passthrough: register " Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 09/10] xen, gfx passthrough: register host bridge specific to passthrough Tiejun Chen
2015-07-15  5:37 ` [Qemu-devel] [v10][PATCH 10/10] xen, gfx passthrough: add opregion mapping Tiejun Chen
2015-07-15 11:46 ` [Qemu-devel] [v10][PATCH 00/10] xen: add Intel IGD passthrough Stefano Stabellini
2015-07-15 12:01   ` Michael S. Tsirkin
2015-07-15 12:38     ` Stefano Stabellini
2015-07-15 13:27       ` Chen, Tiejun

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=20160209104332.775b88f8@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=allen.m.kay@intel.com \
    --cc=ehabkost@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=stefano.stabellini@eu.citrix.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).