From: Ross Philipson <ross.philipson@citrix.com>
To: xen-devel <xen-devel@lists.xen.org>
Cc: Ian Campbell <ian.campbell@citrix.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
"G.R." <firemeteor@users.sourceforge.net>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
Jean Guyader <Jean.guyader@gmail.com>
Subject: Re: [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci cap on host bridge.
Date: Tue, 25 Jun 2013 10:08:14 -0400 [thread overview]
Message-ID: <51C9A44E.1050309@citrix.com> (raw)
In-Reply-To: <20130621180335.GC15809@phenom.dumpdata.com>
On 06/21/2013 02:03 PM, Konrad Rzeszutek Wilk wrote:
> 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?
So I actually originally found this issue with the vendor capabilities
and created the original patch for it. This was quite some time ago so I
had to go back and look. IIRC the vendor specific capabilities were
always the first one in the chain and the unchaining code would drop all
further capabilities (which we did not want to pass directly to the guest).
We never saw a configuration where the vendor capabilities were not the
first. I guess the suggestion is that to make the patch consistent,
preceding capabilities should be detected and handled. I am not sure
what the best way to do it would be. Perhaps scanning through the chain
until 0x09 is found and reporting its offset through 0x34 instead of
what is there would be the way to go. Then unchain anything past the
0x09 caps too as is currently done.
>>
>> Thanks,
>> Timothy
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-06-25 14:08 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-07 16:12 Patch series for IGD passthrough Rui Guo
2013-02-07 16:12 ` [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear all MSI flags Rui Guo
2013-02-07 16:12 ` [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge for IGD passthrough Rui Guo
2013-02-07 16:30 ` Jan Beulich
2013-02-07 17:43 ` G.R.
2013-02-08 7:51 ` Jan Beulich
2013-05-21 15:39 ` G.R.
2013-05-24 4:02 ` G.R.
2013-02-08 11:30 ` Stefano Stabellini
2013-02-08 11:36 ` Jan Beulich
2013-02-08 11:48 ` Stefano Stabellini
2013-05-21 15:52 ` G.R.
2013-05-21 15:57 ` Jan Beulich
2013-02-07 16:12 ` [PATCH 3/3] qemu-xen-trad: IGD passthrough: Expose vendor specific pci cap on host bridge Rui Guo
2013-02-07 16:40 ` Jan Beulich
2013-02-07 17:38 ` G.R.
2013-02-08 7:56 ` Jan Beulich
2013-06-19 10:37 ` G.R.
2013-06-21 18:03 ` Konrad Rzeszutek Wilk
2013-06-25 14:08 ` Ross Philipson [this message]
2013-06-25 14:54 ` Konrad Rzeszutek Wilk
2013-06-25 15:01 ` Ross Philipson
2013-06-26 4:18 ` G.R.
2013-06-26 12:53 ` Konrad Rzeszutek Wilk
2013-06-26 17:26 ` Ross Philipson
2013-06-27 7:27 ` G.R.
2013-07-01 13:06 ` Konrad Rzeszutek Wilk
2013-07-15 16:06 ` Pasi Kärkkäinen
2013-07-15 17:47 ` Ross Philipson
2013-07-15 22:55 ` Pasi Kärkkäinen
2013-08-05 16:15 ` Pasi Kärkkäinen
2013-08-06 3:44 ` G.R.
2013-09-25 14:28 ` Pasi Kärkkäinen
2014-08-20 15:20 ` Pasi Kärkkäinen
2013-06-25 14:26 ` G.R.
2013-02-08 11:14 ` Patch series for IGD passthrough Stefano Stabellini
2013-03-20 17:17 ` Pasi Kärkkäinen
2013-04-15 20:48 ` Pasi Kärkkäinen
2013-04-16 10:56 ` George Dunlap
2013-04-16 15:59 ` Pasi Kärkkäinen
2013-04-18 11:48 ` Stefano Stabellini
2012-12-19 13:06 ` [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge " G.R.
2012-12-20 13:13 ` Stefano Stabellini
2013-02-22 18:05 ` Ian Jackson
2013-02-25 10:10 ` Jan Beulich
2013-02-25 11:24 ` Ian Jackson
2013-02-25 11:29 ` Jan Beulich
2013-02-25 12:49 ` Stefano Stabellini
2013-05-07 17:12 ` [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge for IGD passthrough [and 2 more messages] Ian Jackson
2013-05-09 13:17 ` Pasi Kärkkäinen
2013-05-10 9:12 ` Jan Beulich
2013-05-10 9:40 ` Pasi Kärkkäinen
2013-05-10 10:00 ` Ian Campbell
2013-05-10 10:09 ` George Dunlap
2013-05-10 10:33 ` Ian Campbell
2013-05-10 10:44 ` Pasi Kärkkäinen
2013-05-10 10:35 ` Jan Beulich
2013-02-25 16:46 ` [PATCH v2] qemu-xen:Correctly expose PCH ISA bridge for IGD passthrough Ian Jackson
2013-04-18 11:47 ` Patch series " Stefano Stabellini
2013-05-03 15:14 ` Pasi Kärkkäinen
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=51C9A44E.1050309@citrix.com \
--to=ross.philipson@citrix.com \
--cc=JBeulich@suse.com \
--cc=Jean.guyader@gmail.com \
--cc=firemeteor@users.sourceforge.net \
--cc=ian.campbell@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=stefano.stabellini@citrix.com \
--cc=xen-devel@lists.xen.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.