From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose
 vendor specific pci cap on host bridge.
Date: Fri, 21 Jun 2013 14:03:35 -0400
Message-ID: <20130621180335.GC15809@phenom.dumpdata.com>
References: <1360253528-5424-1-git-send-email-firemeteor@users.sourceforge.net>
	<1360253528-5424-4-git-send-email-firemeteor@users.sourceforge.net>
	<5113E71B02000078000BCF86@nat28.tlf.novell.com>
	<CAKhsbWb=QwqD74BdFB2jbB+wmHgFvFvGhePV+gZos5ZxC3KeSw@mail.gmail.com>
	<5114BDC202000078000BD138@nat28.tlf.novell.com>
	<CAKhsbWZSazOtcLV=hbwfDquVbgr9wrh0J=1U-zOgknfEce5TAA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <CAKhsbWZSazOtcLV=hbwfDquVbgr9wrh0J=1U-zOgknfEce5TAA@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "G.R." <firemeteor@users.sourceforge.net>
Cc: xen-devel <xen-devel@lists.xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>, Jean Guyader <Jean.guyader@gmail.com>, Jan Beulich <JBeulich@suse.com>, Ian Campbell <ian.campbell@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Wed, Jun 19, 2013 at 06:37:06PM +0800, G.R. wrote:
> I'm going to rework this patch to address Jan's concern.
> Here is my proposal, please review and comment before I begin:
> 
> The proposal is to read a shadow copy of the exposed host register into
> the config space of the emulated host bridge and relies on the
> pci_default_read_config() function
> to provide proper access.
> 
> This methodology only works for constant values, which is our case here.
> The exposed value is either read-only or write-locked (for BIOS).
> 
> The only exception is that the PAVPC (0x58) register is write-locked
> but not for BIOS.

So only SeaBIOS or hvmloader should touch it?

> This is exposed for RW and my proposal is to perform write-through in
> the register write-support.

What does PAVPC do? As in if the driver wrote 0xdeadbeef in there what
would happen? Is there a list of the appropiate values it should
accept?

> 
> >
> > Also, why would removing the next capability be correct here,
> > when you're not removing _all_ other capabilities?
> I have no answer about this question. *Jean*, could you help comment
> since this is from your code?


If he doesn't answer - if you don't remove the capability does it
still work?
> 
> Thanks,
> Timothy
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>