On Mon, 30 Jun 2014, Michael S. Tsirkin wrote:
> On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> > On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> > >On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> > >>On 2014/6/26 18:03, Paolo Bonzini wrote:
> > >>>Il 26/06/2014 11:
On Mon, Jun 30, 2014 at 05:38:21PM +0800, Chen, Tiejun wrote:
> On 2014/6/30 17:05, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >>>On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> O
On 2014/6/30 17:05, Michael S. Tsirkin wrote:
On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
On 2014/6/30 14:48, Michael S. Tsirkin wrote:
On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
On 2014/6/26 18:03, Paolo Bonzini wrote:
Il 26/06/2014 11:18, Chen, Tiejun ha
On Mon, Jun 30, 2014 at 03:24:58PM +0800, Chen, Tiejun wrote:
> On 2014/6/30 14:48, Michael S. Tsirkin wrote:
> >On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> >>On 2014/6/26 18:03, Paolo Bonzini wrote:
> >>>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
>
> >
> >- offs
On 2014/6/30 14:48, Michael S. Tsirkin wrote:
On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
On 2014/6/26 18:03, Paolo Bonzini wrote:
Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
- offsets 0x..0x0fff map to configuration space of the host MCH
Are you saying the config
On Mon, Jun 30, 2014 at 10:51:49AM +0800, Chen, Tiejun wrote:
> On 2014/6/26 18:03, Paolo Bonzini wrote:
> >Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>
> >>>
> >>>- offsets 0x..0x0fff map to configuration space of the host MCH
> >>>
> >>
> >>Are you saying the config space in the video d
On 2014/6/26 18:03, Paolo Bonzini wrote:
Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
- offsets 0x..0x0fff map to configuration space of the host MCH
Are you saying the config space in the video device?
No, I am saying in a new BAR, or at some magic offset of an existing
MMIO BAR.
On Thu, Jun 26, 2014 at 03:30:11PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 13:36, Michael S. Tsirkin ha scritto:
> >>It should be this way in real hardware too
> >But it isn't.
>
> That's why I mentioned that this hack should become architecturally
> specified (since it can work on real hardwa
Il 26/06/2014 13:36, Michael S. Tsirkin ha scritto:
It should be this way in real hardware too
But it isn't.
That's why I mentioned that this hack should become architecturally
specified (since it can work on real hardware too) with QEMU doing the
emulation for current-generation devices.
On Thu, Jun 26, 2014 at 01:30:42PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 13:26, Michael S. Tsirkin ha scritto:
> >On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
> >>Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >>>
>
> - offsets 0x..0x0fff map to configuration s
On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
> Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
> >
> >>
> >>- offsets 0x..0x0fff map to configuration space of the host MCH
> >>
> >
> >Are you saying the config space in the video device?
>
> No, I am saying in a new BAR, or at s
Il 26/06/2014 13:26, Michael S. Tsirkin ha scritto:
On Thu, Jun 26, 2014 at 12:03:58PM +0200, Paolo Bonzini wrote:
Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
- offsets 0x..0x0fff map to configuration space of the host MCH
Are you saying the config space in the video device?
No, I
Il 26/06/2014 11:18, Chen, Tiejun ha scritto:
- offsets 0x..0x0fff map to configuration space of the host MCH
Are you saying the config space in the video device?
No, I am saying in a new BAR, or at some magic offset of an existing
MMIO BAR.
Paolo
On 2014/6/25 17:54, Paolo Bonzini wrote:
Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
For past devices, we know which BARs they use. For future devices, it
would be nice if the PCH/MCH backdoor was specified so that we know they
will leave a free BAR for virtualization.
Now I'm a bit confu
On Wed, Jun 25, 2014 at 04:16:12PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 16:10, Michael S. Tsirkin ha scritto:
> >On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
> >>>OK, so how about doing this: either for the ISA
> >>>br
Il 25/06/2014 16:10, Michael S. Tsirkin ha scritto:
On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
OK, so how about doing this: either for the ISA
bridge, or for the VGA card itself:
set subsystem vendor id to PCI_VENDOR_ID
On Wed, Jun 25, 2014 at 03:53:30PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
> >OK, so how about doing this: either for the ISA
> >bridge, or for the VGA card itself:
> >
> >set subsystem vendor id to PCI_VENDOR_ID_XEN,
> >set subsystem device id to P
Il 25/06/2014 15:47, Michael S. Tsirkin ha scritto:
OK, so how about doing this: either for the ISA
bridge, or for the VGA card itself:
set subsystem vendor id to PCI_VENDOR_ID_XEN,
set subsystem device id to PCH device id
That would work, but the same problem would then arise for the
On Wed, Jun 25, 2014 at 02:11:45PM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 12:21, Michael S. Tsirkin ha scritto:
> >So what if you dont?
> >
> >if (!pch)
> >DRM_DEBUG_KMS("No PCH found.\n");
> >
> >Is that all? Seems harmless enough.
> >
>
> The switch statement above s
Il 25/06/2014 12:21, Michael S. Tsirkin ha scritto:
So what if you dont?
if (!pch)
DRM_DEBUG_KMS("No PCH found.\n");
Is that all? Seems harmless enough.
The switch statement above sets dev_priv->pch_type. If it is set wrong,
everything goes wrong. grep for HAS_PCH_
On Wed, Jun 25, 2014 at 06:37:31PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:32, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 18:21, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> O
On 2014/6/25 18:32, Michael S. Tsirkin wrote:
On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
On 2014/6/25 18:21, Michael S. Tsirkin wrote:
On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
On 2014/6/25 17:59, Paolo Bonzini wrote:
Il 25/06/2014 11:55, Michael S. Tsir
On Wed, Jun 25, 2014 at 05:21:04PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:09, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 16:48, Michael S. Tsirkin wrote:
> >>>On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
>
On Wed, Jun 25, 2014 at 06:28:34PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:21, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> >>On 2014/6/25 17:59, Paolo Bonzini wrote:
> >>>Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >You're saying w
On 2014/6/25 18:21, Michael S. Tsirkin wrote:
On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
On 2014/6/25 17:59, Paolo Bonzini wrote:
Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
You're saying we will reserve a free BAR to address those
information to
expose to guest, b
On Wed, Jun 25, 2014 at 06:15:29PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 18:09, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> You're saying we will reserve a free BAR to address those inf
On Wed, Jun 25, 2014 at 06:06:50PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:59, Paolo Bonzini wrote:
> >Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >>> You're saying we will reserve a free BAR to address those
> >>information to
> >>> expose to guest, but which device does this free B
On 2014/6/25 18:09, Michael S. Tsirkin wrote:
On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
You're saying we will reserve a free BAR to address those information to
expose to guest, but which device does this free BAR belong t
Il 25/06/2014 12:09, Michael S. Tsirkin ha scritto:
> It's not just a couple of IDs, it's also random fields of the MCH
> configuration space. Grep drivers/gpu/drm/i915 for bridge_dev.
>
> Paolo
I did, it seems to look for device at 0,0:
static int i915_get_bridge_dev(struct drm_device
On Wed, Jun 25, 2014 at 11:59:21AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> >> You're saying we will reserve a free BAR to address those information to
> >> expose to guest, but which device does this free BAR belong to? The video
> >> device? Or PCH/MCH?
On 2014/6/25 17:59, Paolo Bonzini wrote:
Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> You're saying we will reserve a free BAR to address those
information to
> expose to guest, but which device does this free BAR belong to? The
video
> device? Or PCH/MCH?
If you just want to pass a co
On Wed, Jun 25, 2014 at 11:54:22AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
> >>
> >>For past devices, we know which BARs they use. For future devices, it
> >>would be nice if the PCH/MCH backdoor was specified so that we know they
> >>will leave a free BAR for v
Il 25/06/2014 11:55, Michael S. Tsirkin ha scritto:
> You're saying we will reserve a free BAR to address those information to
> expose to guest, but which device does this free BAR belong to? The video
> device? Or PCH/MCH?
If you just want to pass a couple of IDs, then don't, it's a waste.
But
On Wed, Jun 25, 2014 at 05:50:16PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 17:31, Paolo Bonzini wrote:
> >Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
> >>>Adding a vendor-specific capability or BAR
> >>>in an existing device is painful - hard to find
> >>>free space for it.
> >>
> >>Yes, this i
Il 25/06/2014 11:50, Chen, Tiejun ha scritto:
For past devices, we know which BARs they use. For future devices, it
would be nice if the PCH/MCH backdoor was specified so that we know they
will leave a free BAR for virtualization.
Now I'm a bit confused about BAR here.
You're saying we will
On 2014/6/25 17:31, Paolo Bonzini wrote:
Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
Adding a vendor-specific capability or BAR
in an existing device is painful - hard to find
free space for it.
Yes, this is a potential risk as well since we can't guarantee current
free space is always valid
Il 25/06/2014 11:21, Chen, Tiejun ha scritto:
Adding a vendor-specific capability or BAR
in an existing device is painful - hard to find
free space for it.
Yes, this is a potential risk as well since we can't guarantee current
free space is always valid for ever.
For past devices, we know whi
On 2014/6/25 17:09, Michael S. Tsirkin wrote:
On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
On 2014/6/25 16:48, Michael S. Tsirkin wrote:
On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
It might be possible to
On Wed, Jun 25, 2014 at 04:55:25PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 16:48, Michael S. Tsirkin wrote:
> >On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
> >>Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> >>>It might be possible to move the Q35 bridge elsewhere.
> >>>se
On 2014/6/25 16:48, Michael S. Tsirkin wrote:
On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
It might be possible to move the Q35 bridge elsewhere.
seabios doesn't care where the host bridge is.
ACPI tables in QEMU can be adjus
On Wed, Jun 25, 2014 at 10:39:43AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
> >It might be possible to move the Q35 bridge elsewhere.
> >seabios doesn't care where the host bridge is.
> >ACPI tables in QEMU can be adjusted.
>
> But why? It's always in 00:1
Il 25/06/2014 10:31, Michael S. Tsirkin ha scritto:
It might be possible to move the Q35 bridge elsewhere.
seabios doesn't care where the host bridge is.
ACPI tables in QEMU can be adjusted.
But why? It's always in 00:1f.0 on real hardware. If the i915 driver
wants to run under virtual machi
On Wed, Jun 25, 2014 at 09:44:14AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 09:35, Chen, Tiejun ha scritto:
> >>How are you going to make this work for Q35 or another PCIe machine that
> >>already has an ISA bridge at 00:1f.0?
> >>
> >
> >Could we simply pass the vendor/device ids of the host IS
Il 25/06/2014 09:15, Michael S. Tsirkin ha scritto:
Maybe it just works?
Is tweaking vendor/device/revision id to match host really necessary?
Yes, the driver inspects the fields and tweaks its behavior according to
them. It also pokes at configuration space of the host bridge. It's
quite d
Il 25/06/2014 09:35, Chen, Tiejun ha scritto:
How are you going to make this work for Q35 or another PCIe machine that
already has an ISA bridge at 00:1f.0?
Could we simply pass the vendor/device ids of the host ISA bridge here?
No, because the firmware then would not recognize the host ISA
On Wed, Jun 25, 2014 at 03:35:51PM +0800, Chen, Tiejun wrote:
> On 2014/6/25 14:19, Paolo Bonzini wrote:
> >Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> >>* Don't set that ISA class property, instead, just fake this ISA bridge
> >> with 00:1f.0.
> >
> >How are you going to make this work for Q35
On 2014/6/25 14:19, Paolo Bonzini wrote:
Il 25/06/2014 04:17, Tiejun Chen ha scritto:
* Don't set that ISA class property, instead, just fake this ISA bridge
with 00:1f.0.
How are you going to make this work for Q35 or another PCIe machine that
already has an ISA bridge at 00:1f.0?
Could
On Wed, Jun 25, 2014 at 08:19:19AM +0200, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> >* Don't set that ISA class property, instead, just fake this ISA bridge
> > with 00:1f.0.
>
> How are you going to make this work for Q35 or another PCIe machine that
> already has an
Il 25/06/2014 04:17, Tiejun Chen ha scritto:
* Don't set that ISA class property, instead, just fake this ISA bridge
with 00:1f.0.
How are you going to make this work for Q35 or another PCIe machine that
already has an ISA bridge at 00:1f.0?
Paolo
V5 is generated just based on Paolo's some comments.
v5:
* Don't set that ISA class property, instead, just fake this ISA bridge
with 00:1f.0.
* Don't pass vendor/device ids in igd_pci_read().
* Add to support offset 0x44/0x48.
* Just rebase.
v4:
* Fix some typos in the patch head description
50 matches
Mail list logo
