From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33409) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTCKA-0005Ex-8f for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:43:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTCK6-0000cf-4q for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:43:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTCK5-0000ca-UJ for qemu-devel@nongnu.org; Tue, 09 Feb 2016 12:43:34 -0500 Date: Tue, 9 Feb 2016 10:43:32 -0700 From: Alex Williamson Message-ID: <20160209104332.775b88f8@t450s.home> In-Reply-To: <20160208203235.69088310@t450s.home> References: <1436938670-7677-1-git-send-email-tiejun.chen@intel.com> <1436938670-7677-4-git-send-email-tiejun.chen@intel.com> <20160208203235.69088310@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthrough List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: ehabkost@redhat.com, stefano.stabellini@eu.citrix.com, mst@redhat.com, "Kay, Allen M" , qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net 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 wrote: > On Wed, 15 Jul 2015 13:37:43 +0800 > Tiejun Chen 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 > > Acked-by: Michael S. Tsirkin > > --- > > 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 >