| Message ID | 1403662641-28526-5-git-send-email-tiejun.chen@intel.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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.
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. >
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. > > >
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. >>> >> >
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. > > > > > > > > > >
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. > > > > > > > > > > > > > >
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. > > > > > > > > > > > > > > > > > >
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);
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(-)