[v5,4/5] xen, gfx passthrough: create host bridge to passthrough
diff mbox

Message ID 1403662641-28526-5-git-send-email-tiejun.chen@intel.com
State New
Headers show

Commit Message

Tiejun Chen June 25, 2014, 2:17 a.m. UTC
Implement that pci host bridge to specific to passthrough. Actually
this just inherit the standard one.

Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
---
v5:

* Nothing is changed.

v4:

* Fix one typo in the patch head description.
* Use (xen_enabled() && xen_has_gfx_passthru) to make sure we only work
  in this scenario.

v3:

* Just fix this patch head description typo.

v2:

* New patch.

 hw/pci-host/piix.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 54 insertions(+), 2 deletions(-)

Comments

Paolo Bonzini June 25, 2014, 6:24 a.m. UTC | #1
Il 25/06/2014 04:17, Tiejun Chen ha scritto:
> +    if (xen_enabled() && xen_has_gfx_passthru) {
> +        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
> +        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
> +        pci_create_pch(b);
> +    } else {
> +        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
> +        *pi440fx_state = I440FX_PCI_DEVICE(d);
> +    }

As mentioned in the review of v4, this should be a separate, 
Xen-specific machine.  pci_create_pch should not be called in generic PC 
code.

Paolo
Tiejun Chen June 27, 2014, 8:34 a.m. UTC | #2
On 2014/6/25 14:24, Paolo Bonzini wrote:
> Il 25/06/2014 04:17, Tiejun Chen ha scritto:
>> +    if (xen_enabled() && xen_has_gfx_passthru) {
>> +        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
>> +        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
>> +        pci_create_pch(b);
>> +    } else {
>> +        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
>> +        *pi440fx_state = I440FX_PCI_DEVICE(d);
>> +    }
>
> As mentioned in the review of v4, this should be a separate,
> Xen-specific machine.  pci_create_pch should not be called in generic PC
> code.
>

I track this path:

qemu_register_pc_machine(&xenfv_machine);
	|
	+ .init = pc_xen_hvm_init,
		|
		+ pc_init_pci(machine);
			|
			+ pc_init1(machine, 1, 1);
				|
				+ i440fx_init()

So how to separate this to specific to xen? Or you mean we need to 
create an new machine to address this scenario? But actually this is 
same as xenfv_machine except for these little codes.

If you don't like this involve other cases, we may drop this chunk of 
codes as a function to tweak with CONFIG_XEN. But this is not good as 
well since this is device feature, so kvm may need this one day.


Thanks
Tiejun
Paolo Bonzini June 27, 2014, 11:26 a.m. UTC | #3
Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>
>
> So how to separate this to specific to xen? Or you mean we need to
> create an new machine to address this scenario? But actually this is
> same as xenfv_machine except for these little codes.

Yes, please create a new machine so that "-M pc" doesn't have any of 
these hacks.

Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the 
default).

Paolo
Tiejun Chen June 29, 2014, 7:56 a.m. UTC | #4
On 2014/6/27 19:26, Paolo Bonzini wrote:
> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>
>>
>> So how to separate this to specific to xen? Or you mean we need to
>> create an new machine to address this scenario? But actually this is
>> same as xenfv_machine except for these little codes.
>
> Yes, please create a new machine so that "-M pc" doesn't have any of
> these hacks.

But regardless of the machine is 'xenfv' or 'pc', we always call 
pc_init_pci(), then inside, i440fx_init() is always performed. So I 
think even we create a new machine, shouldn't we still call pc_init_pci()?

>
> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> default).
>

Yes, Xen can use 'pc'.

Thanks
Tiejun
Michael S. Tsirkin June 29, 2014, 12:14 p.m. UTC | #5
On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> On 2014/6/27 19:26, Paolo Bonzini wrote:
> >Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> >>
> >>
> >>So how to separate this to specific to xen? Or you mean we need to
> >>create an new machine to address this scenario? But actually this is
> >>same as xenfv_machine except for these little codes.
> >
> >Yes, please create a new machine so that "-M pc" doesn't have any of
> >these hacks.
> 
> But regardless of the machine is 'xenfv' or 'pc', we always call
> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
> even we create a new machine, shouldn't we still call pc_init_pci()?
> 
> >
> >Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> >default).
> >
> 
> Yes, Xen can use 'pc'.
> 
> Thanks
> Tiejun

You are creating a new machine type where the pci host
looks like MCH but a bunch of other things are from i440fx.

I have some doubts about this combination being worth supporting - it
does not seem useful for anything except xen from the code you posted,
but maybe you can whittle down the number of places where you poke at
the host to make it reasonable: I can imagine that, if you are lucky and
the registers that i915 wants to poke to make it work on real hardware
happen to fall on top of reserved registers in the i440FX/PIIX3 pci
bridge.  OTOH it would be much more likely if you just start with
something that does have MCH, like Q35, or emulate a newer
machine type.  This is the path that people who wanted
to boot iOS on QEMU took, and the result is pretty good.

But regardless, this is clearly not a i440fx nor a q35 pc
so it needs a separate name.
Tiejun Chen June 30, 2014, 2:52 a.m. UTC | #6
On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
>> On 2014/6/27 19:26, Paolo Bonzini wrote:
>>> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>>>
>>>>
>>>> So how to separate this to specific to xen? Or you mean we need to
>>>> create an new machine to address this scenario? But actually this is
>>>> same as xenfv_machine except for these little codes.
>>>
>>> Yes, please create a new machine so that "-M pc" doesn't have any of
>>> these hacks.
>>
>> But regardless of the machine is 'xenfv' or 'pc', we always call
>> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
>> even we create a new machine, shouldn't we still call pc_init_pci()?
>>
>>>
>>> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
>>> default).
>>>
>>
>> Yes, Xen can use 'pc'.
>>
>> Thanks
>> Tiejun
>
> You are creating a new machine type where the pci host
> looks like MCH but a bunch of other things are from i440fx.

Anthony,

Any comments to address this in xen case?

Thanks
Tiejun

>
> I have some doubts about this combination being worth supporting - it
> does not seem useful for anything except xen from the code you posted,
> but maybe you can whittle down the number of places where you poke at
> the host to make it reasonable: I can imagine that, if you are lucky and
> the registers that i915 wants to poke to make it work on real hardware
> happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> bridge.  OTOH it would be much more likely if you just start with
> something that does have MCH, like Q35, or emulate a newer
> machine type.  This is the path that people who wanted
> to boot iOS on QEMU took, and the result is pretty good.
>
> But regardless, this is clearly not a i440fx nor a q35 pc
> so it needs a separate name.
>
Stefano Stabellini June 30, 2014, 7:42 p.m. UTC | #7
On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > 
> > > > > 
> > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > create an new machine to address this scenario? But actually this is
> > > > > same as xenfv_machine except for these little codes.
> > > > 
> > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > these hacks.
> > > 
> > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > pc_init_pci(), then inside, i440fx_init() is always performed. So I think
> > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > 
> > > > 
> > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > default).
> > > > 
> > > 
> > > Yes, Xen can use 'pc'.
> > > 
> > > Thanks
> > > Tiejun
> > 
> > You are creating a new machine type where the pci host
> > looks like MCH but a bunch of other things are from i440fx.
> 
> Anthony,
> 
> Any comments to address this in xen case?

Having a separate machine for this is reasonable. You can select the
right one from libxl anyway. From the name point of view I would go with
"xenigd".
Just take a look at xenfv and introduce something similar but specific
to your IGD PT use case.


> Thanks
> Tiejun
> 
> > 
> > I have some doubts about this combination being worth supporting - it
> > does not seem useful for anything except xen from the code you posted,
> > but maybe you can whittle down the number of places where you poke at
> > the host to make it reasonable: I can imagine that, if you are lucky and
> > the registers that i915 wants to poke to make it work on real hardware
> > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > bridge.  OTOH it would be much more likely if you just start with
> > something that does have MCH, like Q35, or emulate a newer
> > machine type.  This is the path that people who wanted
> > to boot iOS on QEMU took, and the result is pretty good.
> > 
> > But regardless, this is clearly not a i440fx nor a q35 pc
> > so it needs a separate name.
> > 
>
Tiejun Chen July 1, 2014, 2:19 a.m. UTC | #8
On 2014/7/1 3:42, Stefano Stabellini wrote:
> On Mon, 30 Jun 2014, Chen, Tiejun wrote:
>> On 2014/6/29 20:14, Michael S. Tsirkin wrote:
>>> On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
>>>> On 2014/6/27 19:26, Paolo Bonzini wrote:
>>>>> Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
>>>>>>
>>>>>>
>>>>>> So how to separate this to specific to xen? Or you mean we need to
>>>>>> create an new machine to address this scenario? But actually this is
>>>>>> same as xenfv_machine except for these little codes.
>>>>>
>>>>> Yes, please create a new machine so that "-M pc" doesn't have any of
>>>>> these hacks.
>>>>
>>>> But regardless of the machine is 'xenfv' or 'pc', we always call
>>>> pc_init_pci(), then inside, i440fx_init() is always performed. So I think
>>>> even we create a new machine, shouldn't we still call pc_init_pci()?
>>>>
>>>>>
>>>>> Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
>>>>> default).
>>>>>
>>>>
>>>> Yes, Xen can use 'pc'.
>>>>
>>>> Thanks
>>>> Tiejun
>>>
>>> You are creating a new machine type where the pci host
>>> looks like MCH but a bunch of other things are from i440fx.
>>
>> Anthony,
>>
>> Any comments to address this in xen case?
>
> Having a separate machine for this is reasonable. You can select the
> right one from libxl anyway. From the name point of view I would go with
> "xenigd".

Do this mean we need to change something libxl?

> Just take a look at xenfv and introduce something similar but specific
> to your IGD PT use case.
>

Which PCIe machine should I refer? i440fx or q35?

Thanks
Tiejun

>
>> Thanks
>> Tiejun
>>
>>>
>>> I have some doubts about this combination being worth supporting - it
>>> does not seem useful for anything except xen from the code you posted,
>>> but maybe you can whittle down the number of places where you poke at
>>> the host to make it reasonable: I can imagine that, if you are lucky and
>>> the registers that i915 wants to poke to make it work on real hardware
>>> happen to fall on top of reserved registers in the i440FX/PIIX3 pci
>>> bridge.  OTOH it would be much more likely if you just start with
>>> something that does have MCH, like Q35, or emulate a newer
>>> machine type.  This is the path that people who wanted
>>> to boot iOS on QEMU took, and the result is pretty good.
>>>
>>> But regardless, this is clearly not a i440fx nor a q35 pc
>>> so it needs a separate name.
>>>
>>
>
Stefano Stabellini July 1, 2014, 4:49 p.m. UTC | #9
On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> On 2014/7/1 3:42, Stefano Stabellini wrote:
> > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > 
> > > > > > > 
> > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > is
> > > > > > > same as xenfv_machine except for these little codes.
> > > > > > 
> > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > these hacks.
> > > > > 
> > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > think
> > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > 
> > > > > > 
> > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > default).
> > > > > > 
> > > > > 
> > > > > Yes, Xen can use 'pc'.
> > > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > 
> > > > You are creating a new machine type where the pci host
> > > > looks like MCH but a bunch of other things are from i440fx.
> > > 
> > > Anthony,
> > > 
> > > Any comments to address this in xen case?
> > 
> > Having a separate machine for this is reasonable. You can select the
> > right one from libxl anyway. From the name point of view I would go with
> > "xenigd".
> 
> Do this mean we need to change something libxl?

Yes: you would need to pass a different -machine option, see
tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
It would be a pretty small change.

> > Just take a look at xenfv and introduce something similar but specific
> > to your IGD PT use case.
> > 
> 
> Which PCIe machine should I refer? i440fx or q35?

I'd say i440fx.


> Thanks
> Tiejun
> 
> > 
> > > Thanks
> > > Tiejun
> > > 
> > > > 
> > > > I have some doubts about this combination being worth supporting - it
> > > > does not seem useful for anything except xen from the code you posted,
> > > > but maybe you can whittle down the number of places where you poke at
> > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > the registers that i915 wants to poke to make it work on real hardware
> > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > bridge.  OTOH it would be much more likely if you just start with
> > > > something that does have MCH, like Q35, or emulate a newer
> > > > machine type.  This is the path that people who wanted
> > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > 
> > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > so it needs a separate name.
> > > > 
> > > 
> > 
>
Michael S. Tsirkin July 1, 2014, 6:34 p.m. UTC | #10
On Tue, Jul 01, 2014 at 05:49:50PM +0100, Stefano Stabellini wrote:
> On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> > On 2014/7/1 3:42, Stefano Stabellini wrote:
> > > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > > is
> > > > > > > > same as xenfv_machine except for these little codes.
> > > > > > > 
> > > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > > these hacks.
> > > > > > 
> > > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > > think
> > > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > > 
> > > > > > > 
> > > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > > default).
> > > > > > > 
> > > > > > 
> > > > > > Yes, Xen can use 'pc'.
> > > > > > 
> > > > > > Thanks
> > > > > > Tiejun
> > > > > 
> > > > > You are creating a new machine type where the pci host
> > > > > looks like MCH but a bunch of other things are from i440fx.
> > > > 
> > > > Anthony,
> > > > 
> > > > Any comments to address this in xen case?
> > > 
> > > Having a separate machine for this is reasonable. You can select the
> > > right one from libxl anyway. From the name point of view I would go with
> > > "xenigd".
> > 
> > Do this mean we need to change something libxl?
> 
> Yes: you would need to pass a different -machine option, see
> tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
> It would be a pretty small change.
> 
> > > Just take a look at xenfv and introduce something similar but specific
> > > to your IGD PT use case.
> > > 
> > 
> > Which PCIe machine should I refer? i440fx or q35?
> 
> I'd say i440fx.

I have some doubts this can work cleanly, but if you want to attempt
this, be my guest.

So what you want is really franken-i440fx which has this fake isa bridge
and a mixed config from piix and mch.
The idea seems to be to make existing guests work, in light of this I
really don't see the point of pushing any guest changes.

So first step is just to implement these two, they should have nothing
to do with xen specifically, should work fine on all hosts, with tcg,kvm
etc. ISA bridge would just appearing as dummy device there.
Get flags as features for now.
Optionally, as an extra user-friendly feature, you can add a flag
that lets you poke at host and get device IDs etc from sysfs there.
Pls make this a separate patch though, and we'll discuss this
separately.

Same requirement would apply to q35 really - it's not
specific to i440fx.

Also please don't push more guest code upstream until qemu has something
merged or close to being merged.  You are just creating more messy
configurations that have to be supported.


> 
> > Thanks
> > Tiejun
> > 
> > > 
> > > > Thanks
> > > > Tiejun
> > > > 
> > > > > 
> > > > > I have some doubts about this combination being worth supporting - it
> > > > > does not seem useful for anything except xen from the code you posted,
> > > > > but maybe you can whittle down the number of places where you poke at
> > > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > > the registers that i915 wants to poke to make it work on real hardware
> > > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > > bridge.  OTOH it would be much more likely if you just start with
> > > > > something that does have MCH, like Q35, or emulate a newer
> > > > > machine type.  This is the path that people who wanted
> > > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > > 
> > > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > > so it needs a separate name.
> > > > > 
> > > > 
> > > 
> >
Michael S. Tsirkin July 1, 2014, 6:45 p.m. UTC | #11
On Tue, Jul 01, 2014 at 09:34:14PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jul 01, 2014 at 05:49:50PM +0100, Stefano Stabellini wrote:
> > On Tue, 1 Jul 2014, Chen, Tiejun wrote:
> > > On 2014/7/1 3:42, Stefano Stabellini wrote:
> > > > On Mon, 30 Jun 2014, Chen, Tiejun wrote:
> > > > > On 2014/6/29 20:14, Michael S. Tsirkin wrote:
> > > > > > On Sun, Jun 29, 2014 at 03:56:10PM +0800, Chen, Tiejun wrote:
> > > > > > > On 2014/6/27 19:26, Paolo Bonzini wrote:
> > > > > > > > Il 27/06/2014 10:34, Chen, Tiejun ha scritto:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > So how to separate this to specific to xen? Or you mean we need to
> > > > > > > > > create an new machine to address this scenario? But actually this
> > > > > > > > > is
> > > > > > > > > same as xenfv_machine except for these little codes.
> > > > > > > > 
> > > > > > > > Yes, please create a new machine so that "-M pc" doesn't have any of
> > > > > > > > these hacks.
> > > > > > > 
> > > > > > > But regardless of the machine is 'xenfv' or 'pc', we always call
> > > > > > > pc_init_pci(), then inside, i440fx_init() is always performed. So I
> > > > > > > think
> > > > > > > even we create a new machine, shouldn't we still call pc_init_pci()?
> > > > > > > 
> > > > > > > > 
> > > > > > > > Note that "-M xenfv" is obsolete, Xen can now use "-M pc" (i.e. the
> > > > > > > > default).
> > > > > > > > 
> > > > > > > 
> > > > > > > Yes, Xen can use 'pc'.
> > > > > > > 
> > > > > > > Thanks
> > > > > > > Tiejun
> > > > > > 
> > > > > > You are creating a new machine type where the pci host
> > > > > > looks like MCH but a bunch of other things are from i440fx.
> > > > > 
> > > > > Anthony,
> > > > > 
> > > > > Any comments to address this in xen case?
> > > > 
> > > > Having a separate machine for this is reasonable. You can select the
> > > > right one from libxl anyway. From the name point of view I would go with
> > > > "xenigd".
> > > 
> > > Do this mean we need to change something libxl?
> > 
> > Yes: you would need to pass a different -machine option, see
> > tools/libxl/libxl_dm.c:libxl__build_device_model_args_new.
> > It would be a pretty small change.
> > 
> > > > Just take a look at xenfv and introduce something similar but specific
> > > > to your IGD PT use case.
> > > > 
> > > 
> > > Which PCIe machine should I refer? i440fx or q35?
> > 
> > I'd say i440fx.
> 
> I have some doubts this can work cleanly, but if you want to attempt
> this, be my guest.
> 
> So what you want is really franken-i440fx which has this fake isa bridge
> and a mixed config from piix and mch.
> The idea seems to be to make existing guests work, in light of this I
> really don't see the point of pushing any guest changes.
> 
> So first step is just to implement these two, they should have nothing
> to do with xen specifically, should work fine on all hosts, with tcg,kvm
> etc. ISA bridge would just appearing as dummy device there.
> Get flags as features for now.
> Optionally, as an extra user-friendly feature, you can add a flag
> that lets you poke at host and get device IDs etc from sysfs there.
> Pls make this a separate patch though, and we'll discuss this
> separately.

Clarification: that's not a promise that it's mergeable if done that
way, we'll have to evaluate the registers that franken-piix overrides
and weight the chances that
1. guest will start poking at more registers in the future
	or
2. piix will want to use them in the future
leading to maintainance problems.

What I saw so far seems too fragile, I hope most of it isn't
actually required.

And this is why I was saying start with an MCH based chipset
instead.


> Same requirement would apply to q35 really - it's not
> specific to i440fx.
> 
> Also please don't push more guest code upstream until qemu has something
> merged or close to being merged.  You are just creating more messy
> configurations that have to be supported.
> 
> 
> > 
> > > Thanks
> > > Tiejun
> > > 
> > > > 
> > > > > Thanks
> > > > > Tiejun
> > > > > 
> > > > > > 
> > > > > > I have some doubts about this combination being worth supporting - it
> > > > > > does not seem useful for anything except xen from the code you posted,
> > > > > > but maybe you can whittle down the number of places where you poke at
> > > > > > the host to make it reasonable: I can imagine that, if you are lucky and
> > > > > > the registers that i915 wants to poke to make it work on real hardware
> > > > > > happen to fall on top of reserved registers in the i440FX/PIIX3 pci
> > > > > > bridge.  OTOH it would be much more likely if you just start with
> > > > > > something that does have MCH, like Q35, or emulate a newer
> > > > > > machine type.  This is the path that people who wanted
> > > > > > to boot iOS on QEMU took, and the result is pretty good.
> > > > > > 
> > > > > > But regardless, this is clearly not a i440fx nor a q35 pc
> > > > > > so it needs a separate name.
> > > > > > 
> > > > > 
> > > > 
> > >

Patch
diff mbox

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index e0e0946..9acf901 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -34,6 +34,7 @@ 
 #include "sysemu/sysemu.h"
 #include "hw/i386/ioapic.h"
 #include "qapi/visitor.h"
+#include "hw/xen/xen_pt.h"
 
 /*
  * I440FX chipset data sheet.
@@ -95,6 +96,10 @@  typedef struct PIIX3State {
 #define I440FX_PCI_DEVICE(obj) \
     OBJECT_CHECK(PCII440FXState, (obj), TYPE_I440FX_PCI_DEVICE)
 
+#define TYPE_I440FX_XEN_PCI_DEVICE "i440FX-xen"
+#define I440FX_XEN_PCI_DEVICE(obj) \
+    OBJECT_CHECK(PCII440FXState, (obj), TYPE_I440FX_XEN_PCI_DEVICE)
+
 struct PCII440FXState {
     /*< private >*/
     PCIDevice parent_obj;
@@ -305,6 +310,16 @@  static int i440fx_initfn(PCIDevice *dev)
     return 0;
 }
 
+static int i440fx_xen_initfn(PCIDevice *dev)
+{
+    PCII440FXState *d = I440FX_XEN_PCI_DEVICE(dev);
+
+    dev->config[I440FX_SMRAM] = 0x02;
+
+    cpu_smm_register(&i440fx_set_smm, d);
+    return 0;
+}
+
 PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
                     int *piix3_devfn,
                     ISABus **isa_bus, qemu_irq *pic,
@@ -333,8 +348,15 @@  PCIBus *i440fx_init(PCII440FXState **pi440fx_state,
     object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev), NULL);
     qdev_init_nofail(dev);
 
-    d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
-    *pi440fx_state = I440FX_PCI_DEVICE(d);
+    if (xen_enabled() && xen_has_gfx_passthru) {
+        d = pci_create_simple(b, 0, TYPE_I440FX_XEN_PCI_DEVICE);
+        *pi440fx_state = I440FX_XEN_PCI_DEVICE(d);
+        pci_create_pch(b);
+    } else {
+        d = pci_create_simple(b, 0, TYPE_I440FX_PCI_DEVICE);
+        *pi440fx_state = I440FX_PCI_DEVICE(d);
+    }
+
     f = *pi440fx_state;
     f->system_memory = address_space_mem;
     f->pci_address_space = pci_address_space;
@@ -704,6 +726,35 @@  static const TypeInfo i440fx_info = {
     .class_init    = i440fx_class_init,
 };
 
+static void i440fx_xen_class_init(ObjectClass *klass, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(klass);
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = i440fx_xen_initfn;
+    k->config_write = igd_pci_write;
+    k->config_read = igd_pci_read;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82441;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+    dc->desc = "XEN Host bridge";
+    dc->vmsd = &vmstate_i440fx;
+    /*
+     * PCI-facing part of the host bridge, not usable without the
+     * host-facing part, which can't be device_add'ed, yet.
+     */
+    dc->cannot_instantiate_with_device_add_yet = true;
+    dc->hotpluggable   = false;
+}
+
+static const TypeInfo i440fx_xen_info = {
+    .name          = TYPE_I440FX_XEN_PCI_DEVICE,
+    .parent        = TYPE_PCI_DEVICE,
+    .instance_size = sizeof(PCII440FXState),
+    .class_init    = i440fx_xen_class_init,
+};
+
 static const char *i440fx_pcihost_root_bus_path(PCIHostState *host_bridge,
                                                 PCIBus *rootbus)
 {
@@ -745,6 +796,7 @@  static const TypeInfo i440fx_pcihost_info = {
 static void i440fx_register_types(void)
 {
     type_register_static(&i440fx_info);
+    type_register_static(&i440fx_xen_info);
     type_register_static(&piix3_info);
     type_register_static(&piix3_xen_info);
     type_register_static(&i440fx_pcihost_info);