From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com,
qemu-devel@nongnu.org,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough
Date: Mon, 01 Sep 2014 10:50:37 +0800 [thread overview]
Message-ID: <5403DEFD.1020704@intel.com> (raw)
In-Reply-To: <20140831085857.GC1514@redhat.com>
On 2014/8/31 16:58, Michael S. Tsirkin wrote:
> On Fri, Aug 29, 2014 at 09:28:50AM +0800, Chen, Tiejun wrote:
>>
>>
>> On 2014/8/28 8:56, Chen, Tiejun wrote:
>>>>>>>>> + */
>>>>>>>>> + dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
>>>>>>>>> + "xen-igd-passthrough-isa-bridge");
>>>>>>>>> + if (dev) {
>>>>>>>>> + r = xen_host_pci_device_get(&hdev, 0, 0, PCI_DEVFN(0x1f,
>>>>>>>>> 0), 0);
>>>>>>>>> + if (!r) {
>>>>>>>>> + pci_config_set_vendor_id(dev->config, hdev.vendor_id);
>>>>>>>>> + pci_config_set_device_id(dev->config, hdev.device_id);
>>>>>>
>>>>>> Can you, instead, implement the reverse logic, probing
>>>>>> the card and supplying the correct device id for PCH?
>>>>>>
>>>>>
>>>>> Here what is your so-called reverse logic as I already asked you
>>>>> previously? Do you mean I should list all PCHs with a combo illustrated
>>>>> with the vendor/device id in advance? Then look up if we can find a
>>>>
>>>> Michael,
>>>>
>>>
>>> Ping.
>>>
>>> Thanks
>>> Tiejun
>>>
>>>> Could you explain this exactly? Then I can try follow-up your idea ASAP
>>>> if this is necessary and possible.
>>
>> Michel,
>>
>> Could you give us some explanation for your "reverse logic" when you're
>> free?
>>
>> Thanks
>> Tiejun
>
> So future drivers will look at device ID for the card
> and figure out how things should work from there.
> Old drivers still poke at device id of the chipset for this,
> but maybe qemu can do what newer drivers do:
> look at the card and figure out what guest should do,
> then present the appropriate chipset id.
>
> This is based on what Jesse said:
> Practically speaking, we could probably assume specific GPU/PCH combos,
> as I don't think they're generally mixed across generations, though SNB
> and IVB did have compatible sockets, so there is the possibility of
> mixing CPT and PPT PCHs, but those are register identical as far as the
> graphics driver is concerned, so even that should be safe.
>
Michael,
Thanks for your explanation.
> so the idea is to have a reverse table mapping GPU back to PCH.
> Present to guest the ID that will let it assume the correct GPU.
I guess you mean we should create to maintain such a table:
[GPU Card: device_id(s), PCH: device_id]
Then each time, instead of exposing that real PCH device id directly,
qemu first can get the real GPU device id to lookup this table to
present a appropriate PCH's device id to the guest.
And looks here that appropriate PCH's device id is not always a that
real PCH's device id. Right? If I'm wrong please correct me.
>
> the problem with these tables is they are hard to keep up to date
Yeah. But I think currently we can just start from some modern CPU such
as HSW and BDW, then things could be easy.
Allen,
Any idea to this suggestion?
> as new hardware comes out, but as future hardware won't need
> these hacks, we shall be fine.
Yeah.
Thanks
Tiejun
>
>
>>>>
>>>> Thanks
>>>> Tiejun
>>>>
>>>>> matched PCH? If yes, what is that benefit you expect in passthrough
>>>>> case? Shouldn't we pass these info to VM directly in passthrough case?
>>>>>
>>>>> Thanks
>>>>> Tiejun
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
WARNING: multiple messages have this Message-ID (diff)
From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: xen-devel@lists.xensource.com, allen.m.kay@intel.com,
qemu-devel@nongnu.org,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen:i386:pc_piix: create isa bridge specific to IGD passthrough
Date: Mon, 01 Sep 2014 10:50:37 +0800 [thread overview]
Message-ID: <5403DEFD.1020704@intel.com> (raw)
In-Reply-To: <20140831085857.GC1514@redhat.com>
On 2014/8/31 16:58, Michael S. Tsirkin wrote:
> On Fri, Aug 29, 2014 at 09:28:50AM +0800, Chen, Tiejun wrote:
>>
>>
>> On 2014/8/28 8:56, Chen, Tiejun wrote:
>>>>>>>>> + */
>>>>>>>>> + dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
>>>>>>>>> + "xen-igd-passthrough-isa-bridge");
>>>>>>>>> + if (dev) {
>>>>>>>>> + r = xen_host_pci_device_get(&hdev, 0, 0, PCI_DEVFN(0x1f,
>>>>>>>>> 0), 0);
>>>>>>>>> + if (!r) {
>>>>>>>>> + pci_config_set_vendor_id(dev->config, hdev.vendor_id);
>>>>>>>>> + pci_config_set_device_id(dev->config, hdev.device_id);
>>>>>>
>>>>>> Can you, instead, implement the reverse logic, probing
>>>>>> the card and supplying the correct device id for PCH?
>>>>>>
>>>>>
>>>>> Here what is your so-called reverse logic as I already asked you
>>>>> previously? Do you mean I should list all PCHs with a combo illustrated
>>>>> with the vendor/device id in advance? Then look up if we can find a
>>>>
>>>> Michael,
>>>>
>>>
>>> Ping.
>>>
>>> Thanks
>>> Tiejun
>>>
>>>> Could you explain this exactly? Then I can try follow-up your idea ASAP
>>>> if this is necessary and possible.
>>
>> Michel,
>>
>> Could you give us some explanation for your "reverse logic" when you're
>> free?
>>
>> Thanks
>> Tiejun
>
> So future drivers will look at device ID for the card
> and figure out how things should work from there.
> Old drivers still poke at device id of the chipset for this,
> but maybe qemu can do what newer drivers do:
> look at the card and figure out what guest should do,
> then present the appropriate chipset id.
>
> This is based on what Jesse said:
> Practically speaking, we could probably assume specific GPU/PCH combos,
> as I don't think they're generally mixed across generations, though SNB
> and IVB did have compatible sockets, so there is the possibility of
> mixing CPT and PPT PCHs, but those are register identical as far as the
> graphics driver is concerned, so even that should be safe.
>
Michael,
Thanks for your explanation.
> so the idea is to have a reverse table mapping GPU back to PCH.
> Present to guest the ID that will let it assume the correct GPU.
I guess you mean we should create to maintain such a table:
[GPU Card: device_id(s), PCH: device_id]
Then each time, instead of exposing that real PCH device id directly,
qemu first can get the real GPU device id to lookup this table to
present a appropriate PCH's device id to the guest.
And looks here that appropriate PCH's device id is not always a that
real PCH's device id. Right? If I'm wrong please correct me.
>
> the problem with these tables is they are hard to keep up to date
Yeah. But I think currently we can just start from some modern CPU such
as HSW and BDW, then things could be easy.
Allen,
Any idea to this suggestion?
> as new hardware comes out, but as future hardware won't need
> these hacks, we shall be fine.
Yeah.
Thanks
Tiejun
>
>
>>>>
>>>> Thanks
>>>> Tiejun
>>>>
>>>>> matched PCH? If yes, what is that benefit you expect in passthrough
>>>>> case? Shouldn't we pass these info to VM directly in passthrough case?
>>>>>
>>>>> Thanks
>>>>> Tiejun
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
next prev parent reply other threads:[~2014-09-01 2:50 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-21 1:28 [Qemu-devel] [PATCH 0/2] qemu:xen: implement isa bridge specific to IGD passthrough Tiejun Chen
2014-08-21 1:28 ` Tiejun Chen
2014-08-21 1:28 ` [Qemu-devel] [PATCH 1/2] hw:xen:xen_pt: register " Tiejun Chen
2014-08-21 1:28 ` Tiejun Chen
2014-08-21 1:28 ` [Qemu-devel] [PATCH 2/2] xen:i386:pc_piix: create " Tiejun Chen
2014-08-21 1:28 ` Tiejun Chen
2014-08-21 16:16 ` [Qemu-devel] [Xen-devel] " Konrad Rzeszutek Wilk
2014-08-21 16:16 ` Konrad Rzeszutek Wilk
2014-08-22 1:06 ` [Qemu-devel] " Chen, Tiejun
2014-08-22 1:06 ` Chen, Tiejun
2014-08-24 11:12 ` [Qemu-devel] " Michael S. Tsirkin
2014-08-24 11:12 ` Michael S. Tsirkin
2014-08-25 5:18 ` [Qemu-devel] " Chen, Tiejun
2014-08-25 5:18 ` Chen, Tiejun
2014-08-26 2:49 ` [Qemu-devel] " Chen, Tiejun
2014-08-26 2:49 ` Chen, Tiejun
2014-08-28 0:56 ` [Qemu-devel] " Chen, Tiejun
2014-08-28 0:56 ` Chen, Tiejun
2014-08-29 1:28 ` [Qemu-devel] " Chen, Tiejun
2014-08-29 1:28 ` Chen, Tiejun
2014-08-31 8:58 ` [Qemu-devel] " Michael S. Tsirkin
2014-08-31 8:58 ` Michael S. Tsirkin
2014-09-01 2:50 ` Chen, Tiejun [this message]
2014-09-01 2:50 ` Chen, Tiejun
2014-09-01 6:05 ` [Qemu-devel] " Michael S. Tsirkin
2014-09-01 6:05 ` Michael S. Tsirkin
2014-09-01 7:49 ` [Qemu-devel] " Chen, Tiejun
2014-09-01 7:49 ` Chen, Tiejun
2014-09-03 1:40 ` [Qemu-devel] " Kay, Allen M
2014-09-03 1:40 ` Kay, Allen M
2014-09-03 6:27 ` [Qemu-devel] " Michael S. Tsirkin
2014-09-03 6:27 ` Michael S. Tsirkin
2014-09-03 15:06 ` [Qemu-devel] " Kay, Allen M
2014-09-03 15:06 ` Kay, Allen M
2014-09-28 2:59 ` [Qemu-devel] " Chen, Tiejun
2014-09-28 2:59 ` Chen, Tiejun
2014-09-28 5:38 ` [Qemu-devel] " Chen, Tiejun
2014-09-28 5:38 ` Chen, Tiejun
2014-10-07 7:27 ` [Qemu-devel] " Michael S. Tsirkin
2014-10-07 7:27 ` Michael S. Tsirkin
2014-10-09 2:16 ` [Qemu-devel] " Chen, Tiejun
2014-10-09 2:16 ` Chen, Tiejun
2014-09-29 10:01 ` [Qemu-devel] " Michael S. Tsirkin
2014-09-29 10:01 ` Michael S. Tsirkin
2014-09-30 2:43 ` [Qemu-devel] " Chen, Tiejun
2014-09-30 2:43 ` Chen, Tiejun
2014-10-07 1:02 ` [Qemu-devel] " Chen, Tiejun
2014-10-07 1:02 ` Chen, Tiejun
2014-10-07 7:26 ` [Qemu-devel] " Michael S. Tsirkin
2014-10-07 7:26 ` Michael S. Tsirkin
2014-10-09 5:53 ` [Qemu-devel] " Chen, Tiejun
2014-10-09 5:53 ` Chen, Tiejun
2014-10-12 9:50 ` [Qemu-devel] " Michael S. Tsirkin
2014-10-12 9:50 ` Michael S. Tsirkin
2014-10-24 7:36 ` [Qemu-devel] " Chen, Tiejun
2014-10-24 7:36 ` Chen, Tiejun
2014-10-24 13:47 ` [Qemu-devel] " Michael S. Tsirkin
2014-10-24 13:47 ` Michael S. Tsirkin
2014-10-30 7:47 ` [Qemu-devel] " Chen, Tiejun
2014-10-30 7:47 ` Chen, Tiejun
2014-11-03 7:48 ` [Qemu-devel] " Chen, Tiejun
2014-11-03 7:48 ` Chen, Tiejun
2014-11-03 11:35 ` [Qemu-devel] " Paolo Bonzini
2014-11-03 11:35 ` Paolo Bonzini
2014-11-03 11:36 ` [Qemu-devel] " Chen, Tiejun
2014-11-03 11:36 ` Chen, Tiejun
2014-11-03 11:47 ` [Qemu-devel] " Chen, Tiejun
2014-11-03 11:47 ` Chen, Tiejun
2014-11-03 12:01 ` [Qemu-devel] " Paolo Bonzini
2014-11-03 12:01 ` Paolo Bonzini
2014-11-03 13:10 ` [Qemu-devel] [Xen-devel] " Michael S. Tsirkin
2014-11-03 13:10 ` Michael S. Tsirkin
2014-11-05 7:23 ` [Qemu-devel] " Chen, Tiejun
2014-11-05 7:23 ` Chen, Tiejun
2014-08-22 18:23 ` [Qemu-devel] " Michael S. Tsirkin
2014-08-22 18:23 ` Michael S. Tsirkin
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=5403DEFD.1020704@intel.com \
--to=tiejun.chen@intel.com \
--cc=allen.m.kay@intel.com \
--cc=konrad.wilk@oracle.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xen-devel@lists.xensource.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 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.