qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthro


From: Alex Williamson
Subject: Re: [Qemu-devel] [v10][PATCH 03/10] piix: create host bridge to passthrough
Date: Tue, 9 Feb 2016 10:43:32 -0700

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 <address@hidden> wrote:

> On Wed, 15 Jul 2015 13:37:43 +0800
> Tiejun Chen <address@hidden> 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 <address@hidden>
> > Acked-by: Michael S. Tsirkin <address@hidden>
> > ---
> > 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 via email to

[Prev in Thread] Current Thread [Next in Thread]