| Message ID | 1400237624-8505-5-git-send-email-tiejun.chen@intel.com |
|---|---|
| State | New |
| Headers | show |
On Fri, May 16, 2014 at 06:53:40PM +0800, Tiejun Chen wrote: > Some VBIOSs and drivers assume the IGD BDF (bus:device:function) is > always 00:02.0, so we need to reserves 00:02.0 for assigned IGD in reserve > guest. > > Signed-off-by: Tiejun Chen <tiejun.chen@intel.com> > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> > --- > v2: > > * Use a common way patch #2 introduce to reserve PCI devfn. > > hw/pci-host/piix.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c > index ffdc853..b6f49bd 100644 > --- a/hw/pci-host/piix.c > +++ b/hw/pci-host/piix.c > @@ -329,6 +329,14 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, > s = PCI_HOST_BRIDGE(dev); > b = pci_bus_new(dev, NULL, pci_address_space, > address_space_io, 0, TYPE_PCI_BUS); > + > + /* > + * Some video bioses and gfx drivers will assume the bdf of IGD is 00:02.0. > + * So user need to set it to 00:02.0 in Xen configure file explicitly, > + * otherwise IGD will fail to work. > + */ > + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); > + And we do this without checking whether PCI passthrough is done. Should it be gated on that? Or is the reason you do it unconditionally because you want to be able to hot-plug an GFX in? > s->bus = b; > object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev), NULL); > qdev_init_nofail(dev); > -- > 1.9.1 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Hi, > + /* > + * Some video bioses and gfx drivers will assume the bdf of IGD is 00:02.0. > + * So user need to set it to 00:02.0 in Xen configure file explicitly, > + * otherwise IGD will fail to work. > + */ > + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); That is asking for trouble. Slot 2 is used by the qemu vga cards by default, and for quite a while (before memory api was merged) it even was impossible to change it. libvirt still places the vga card at slot 2 for that reason -> boom. I wouldn't be surprised if you find that assumption in other management libs / apps too. Why do you need that patch in the first place? It should be possible to configure qemu to not occupy slot 2 if you need it that way. Just pass '-vga none' to qemu. Which you probably want anyway if you pass-through a vga to the guest. And explicitly configure a slot (via addr= property) for all your pci devices. Doing it only for the IGD works too if you list the device before any other pci device on the qemu command line. cheers, Gerd
Il 19/05/2014 08:44, Gerd Hoffmann ha scritto: > Hi, > >> + /* >> + * Some video bioses and gfx drivers will assume the bdf of IGD is 00:02.0. >> + * So user need to set it to 00:02.0 in Xen configure file explicitly, >> + * otherwise IGD will fail to work. >> + */ >> + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); > That is asking for trouble. Slot 2 is used by the qemu vga cards by > default, and for quite a while (before memory api was merged) it even > was impossible to change it. libvirt still places the vga card at slot > 2 for that reason -> boom. I wouldn't be surprised if you find that > assumption in other management libs / apps too. > > Why do you need that patch in the first place? It should be possible to > configure qemu to not occupy slot 2 if you need it that way. Just pass > '-vga none' to qemu. Which you probably want anyway if you pass-through > a vga to the guest. And explicitly configure a slot (via addr= > property) for all your pci devices. Doing it only for the IGD works too > if you list the device before any other pci device on the qemu command > line. > > cheers, > Gerd I already added vga none support on libxl, useful also for this cases: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2e5738ff47b9d2e1948024100f87b1a25fcf004a This patch is already tested and working, for now I not tested and I can't test with intel gpu passthrough, someone can test it with intel gpu passthrough? Thanks for any reply and sorry for my bad english. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Fabio Fantoni wrote on 2014-05-19: > Il 19/05/2014 08:44, Gerd Hoffmann ha scritto: >> Hi, >>> + /* + * Some video bioses and gfx drivers will assume the bdf >>> of IGD is 00:02.0. + * So user need to set it to 00:02.0 in Xen >>> configure file explicitly, + * otherwise IGD will fail to work. + >>> */ + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); >> That is asking for trouble. Slot 2 is used by the qemu vga cards by >> default, and for quite a while (before memory api was merged) it even >> was impossible to change it. libvirt still places the vga card at slot >> 2 for that reason -> boom. I wouldn't be surprised if you find that >> assumption in other management libs / apps too. >> >> Why do you need that patch in the first place? It should be possible to >> configure qemu to not occupy slot 2 if you need it that way. Just pass >> '-vga none' to qemu. Which you probably want anyway if you pass-through >> a vga to the guest. And explicitly configure a slot (via addr= >> property) for all your pci devices. Doing it only for the IGD works too >> if you list the device before any other pci device on the qemu command >> line. >> >> cheers, >> Gerd > > I already added vga none support on libxl, useful also for this cases: > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2e5738ff47b9d2e19480 > 24100f87b1a25fcf004a Thanks for provide such useful information to us. I will try to see whether it can meet our demand. > > This patch is already tested and working, for now I not tested and I > can't test with intel gpu passthrough, someone can test it with intel > gpu passthrough? > > Thanks for any reply and sorry for my bad english. > >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel Best regards, Yang
> -----Original Message----- > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > Sent: Monday, May 19, 2014 2:45 PM > To: Chen, Tiejun > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > xen-devel@lists.xensource.com; weidong.han@intel.com; Kay, Allen M; > qemu-devel@nongnu.org; jean.guyader@eu.citrix.com; > anthony@codemonkey.ws; Zhang, Yang Z > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve > 00:02.0 for INTEL IGD > > Hi, > > > + /* > > + * Some video bioses and gfx drivers will assume the bdf of IGD is > 00:02.0. > > + * So user need to set it to 00:02.0 in Xen configure file explicitly, > > + * otherwise IGD will fail to work. > > + */ > > + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); > > That is asking for trouble. Slot 2 is used by the qemu vga cards by default, and > for quite a while (before memory api was merged) it even was impossible to > change it. libvirt still places the vga card at slot > 2 for that reason -> boom. I wouldn't be surprised if you find that assumption > in other management libs / apps too. > > Why do you need that patch in the first place? It should be possible to > configure qemu to not occupy slot 2 if you need it that way. Just pass '-vga > none' to qemu. Which you probably want anyway if you pass-through a vga to > the guest. And explicitly configure a slot (via addr= I think '-vga none' just guarantees the qemu vga cards doesn't occupy 00:02.0, but this doesn't mean others use this specific slot since in qemu internal, we always pass -1 to assign a slot automatically to register a PCI device. So in some cases, we can't get this slot as we expect since that is already assigned previously before we need this. > property) for all your pci devices. Doing it only for the IGD works too if you list > the device before any other pci device on the qemu command line. So in my test scenario, we can see this information: PCI: slot 2 function 0 not available for xen-pci-passthrough, in use by xen-platform Thanks Tiejun
> -----Original Message----- > From: Fabio Fantoni [mailto:fabio.fantoni@m2r.biz] > Sent: Monday, May 19, 2014 3:48 PM > To: Gerd Hoffmann; Chen, Tiejun > Cc: peter.maydell@linaro.org; xen-devel@lists.xensource.com; > mst@redhat.com; Kay, Allen M; stefano.stabellini@eu.citrix.com; > weidong.han@intel.com; Kelly.Zytaruk@amd.com; > jean.guyader@eu.citrix.com; qemu-devel@nongnu.org; Zhang, Yang Z; > anthony@codemonkey.ws; anthony.perard@citrix.com > Subject: Re: [Xen-devel] [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: > reserve 00:02.0 for INTEL IGD > > Il 19/05/2014 08:44, Gerd Hoffmann ha scritto: > > Hi, > > > >> + /* > >> + * Some video bioses and gfx drivers will assume the bdf of IGD is > 00:02.0. > >> + * So user need to set it to 00:02.0 in Xen configure file explicitly, > >> + * otherwise IGD will fail to work. > >> + */ > >> + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); > > That is asking for trouble. Slot 2 is used by the qemu vga cards by > > default, and for quite a while (before memory api was merged) it even > > was impossible to change it. libvirt still places the vga card at > > slot > > 2 for that reason -> boom. I wouldn't be surprised if you find that > > assumption in other management libs / apps too. > > > > Why do you need that patch in the first place? It should be possible > > to configure qemu to not occupy slot 2 if you need it that way. Just > > pass '-vga none' to qemu. Which you probably want anyway if you > > pass-through a vga to the guest. And explicitly configure a slot (via > > addr= > > property) for all your pci devices. Doing it only for the IGD works > > too if you list the device before any other pci device on the qemu > > command line. > > > > cheers, > > Gerd > > I already added vga none support on libxl, useful also for this cases: > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=2e5738ff47b9d2e19480 > 24100f87b1a25fcf004a > > This patch is already tested and working, for now I not tested and I can't test > with intel gpu passthrough, someone can test it with intel gpu passthrough? > > Thanks for any reply and sorry for my bad english. But I think what we intend is to reserve a specific slot to work vga passthrough on IGD. Thanks Tiejun
> -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Friday, May 16, 2014 10:09 PM > To: Chen, Tiejun > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > xen-devel@lists.xensource.com; weidong.han@intel.com; Kay, Allen M; > qemu-devel@nongnu.org; jean.guyader@eu.citrix.com; > anthony@codemonkey.ws; Zhang, Yang Z > Subject: Re: [Xen-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve 00:02.0 > for INTEL IGD > > On Fri, May 16, 2014 at 06:53:40PM +0800, Tiejun Chen wrote: > > Some VBIOSs and drivers assume the IGD BDF (bus:device:function) is > > always 00:02.0, so we need to reserves 00:02.0 for assigned IGD in > > reserve Fixed. > > > guest. > > > > Signed-off-by: Tiejun Chen <tiejun.chen@intel.com> > > Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> > > --- > > v2: > > > > * Use a common way patch #2 introduce to reserve PCI devfn. > > > > hw/pci-host/piix.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c index > > ffdc853..b6f49bd 100644 > > --- a/hw/pci-host/piix.c > > +++ b/hw/pci-host/piix.c > > @@ -329,6 +329,14 @@ PCIBus *i440fx_init(PCII440FXState > **pi440fx_state, > > s = PCI_HOST_BRIDGE(dev); > > b = pci_bus_new(dev, NULL, pci_address_space, > > address_space_io, 0, TYPE_PCI_BUS); > > + > > + /* > > + * Some video bioses and gfx drivers will assume the bdf of IGD is > 00:02.0. > > + * So user need to set it to 00:02.0 in Xen configure file explicitly, > > + * otherwise IGD will fail to work. > > + */ > > + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); > > + > > And we do this without checking whether PCI passthrough is done. Should it be > gated on that? Or is the reason you do it unconditionally because you want to > be able to hot-plug an GFX in? > To be honest currently we can't support hot-plug an GFX :( But I believe this would come soon. And additionally, as you know XEN and KVM have different way to implement pci-passthrough, so looks its not easy to distinguish these scenarios here. And I think now it may be acceptable just to reserve one specific devfn, right? Or could you have a good way, I can try to improve this point. Thanks Tiejun
On Mon, May 19, 2014 at 09:25:19AM +0000, Chen, Tiejun wrote: > > -----Original Message----- > > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > > Sent: Monday, May 19, 2014 2:45 PM > > To: Chen, Tiejun > > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > > xen-devel@lists.xensource.com; weidong.han@intel.com; Kay, Allen M; > > qemu-devel@nongnu.org; jean.guyader@eu.citrix.com; > > anthony@codemonkey.ws; Zhang, Yang Z > > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve > > 00:02.0 for INTEL IGD > > > > Hi, > > > > > + /* > > > + * Some video bioses and gfx drivers will assume the bdf of IGD is > > 00:02.0. > > > + * So user need to set it to 00:02.0 in Xen configure file explicitly, > > > + * otherwise IGD will fail to work. > > > + */ > > > + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); > > > > That is asking for trouble. Slot 2 is used by the qemu vga cards by default, and > > for quite a while (before memory api was merged) it even was impossible to > > change it. libvirt still places the vga card at slot > > 2 for that reason -> boom. I wouldn't be surprised if you find that assumption > > in other management libs / apps too. > > > > Why do you need that patch in the first place? It should be possible to > > configure qemu to not occupy slot 2 if you need it that way. Just pass '-vga > > none' to qemu. Which you probably want anyway if you pass-through a vga to > > the guest. And explicitly configure a slot (via addr= > > I think '-vga none' just guarantees the qemu vga cards doesn't occupy 00:02.0, but this doesn't mean others use this specific slot since in qemu internal, we always pass -1 to assign a slot automatically to register a PCI device. So in some cases, we can't get this slot as we expect since that is already assigned previously before we need this. So stop doing this. Address -1 is a short-cut intended for humans. In particular we have no way to guarantee that migration works unless you specify addresses explicitly. > > property) for all your pci devices. Doing it only for the IGD works too if you list > > the device before any other pci device on the qemu command line. > > So in my test scenario, we can see this information: > > PCI: slot 2 function 0 not available for xen-pci-passthrough, in use by xen-platform > Thanks > Tiejun I think the best fix is to give priority to devices that supply a specific slot. I'll look into this.
Hi, > I think '-vga none' just guarantees the qemu vga cards doesn't occupy > 00:02.0, but this doesn't mean others use this specific slot since in > qemu internal, we always pass -1 to assign a slot automatically to > register a PCI device. So in some cases, we can't get this slot as we > expect since that is already assigned previously before we need this. Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create pci devices with auto slot assignment, which will occupy slot 2 indeed. Use -device instead to create the devices. > PCI: slot 2 function 0 not available for xen-pci-passthrough, in use by xen-platform Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init creates this automatically. Two options here IMHO: (1) Just move it somewhere else explicitly. For example slot 3, or make it a southbridge function (say 00:01.7). (2) Don't create it automatically, instead expect management add it if needed, using -device xen-plaform,addr=... I personally would suggest to go for #2. As far I know the platform device is only needed if you want attach xenbus devices to the guest (correct?), so creating virtual machines without the xen platform device is a valid use case and you should allow it. cheers, Gerd
> -----Original Message----- > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > Sent: Monday, May 19, 2014 7:23 PM > To: Chen, Tiejun > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > xen-devel@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org; > jean.guyader@eu.citrix.com; anthony@codemonkey.ws; Zhang, Yang Z > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve > 00:02.0 for INTEL IGD > > Hi, > > > I think '-vga none' just guarantees the qemu vga cards doesn't occupy > > 00:02.0, but this doesn't mean others use this specific slot since in > > qemu internal, we always pass -1 to assign a slot automatically to > > register a PCI device. So in some cases, we can't get this slot as we > > expect since that is already assigned previously before we need this. > > Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create pci devices > with auto slot assignment, which will occupy slot 2 indeed. > Use -device instead to create the devices. > Are you saying we have to create the devices explicitly when we want to work IGD vga with passthrough? But how to make sure all user know this workable way? Maybe you suggest we should document somewhere. > > PCI: slot 2 function 0 not available for xen-pci-passthrough, in use > > by xen-platform > > Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init creates this > automatically. Two options here IMHO: > > (1) Just move it somewhere else explicitly. For example slot 3, or > make it a southbridge function (say 00:01.7). > (2) Don't create it automatically, instead expect management add it > if needed, using -device xen-plaform,addr=... > > I personally would suggest to go for #2. As far I know the platform device is > only needed if you want attach xenbus devices to the guest (correct?), so > creating virtual machines without the xen platform device is a valid use case > and you should allow it. > Looks you recommend we should change current xen platform design, I'm not sure if something in libxl also need to be modified. Especially, this may not be compatible with those old xen version. And especially, how to guarantee no one occupy 00:02.0 in the future with auto assign? Thanks Tiejun
Hi, > > Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create pci devices > > with auto slot assignment, which will occupy slot 2 indeed. > > Use -device instead to create the devices. > > > > Are you saying we have to create the devices explicitly when we want > to work IGD vga with passthrough? But how to make sure all user know > this workable way? Maybe you suggest we should document somewhere. libvirt does this unconditionally, because it is a good idea anyway for a number of reasons. Example: create a machine with three pci devices, hot-unplug the second, then live-migrate to another machine. The only way to create the correct config on the target machine is to explicitly assign slots, otherwise the third pci device ends up in the wrong slot. Don't know how the libxl (and xl tool) work. Maybe it does the same anyway. Maybe it can handle the address assignment transparently for the user. > > Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init creates this > > automatically. Two options here IMHO: > > > > (1) Just move it somewhere else explicitly. For example slot 3, or > > make it a southbridge function (say 00:01.7). > > (2) Don't create it automatically, instead expect management add it > > if needed, using -device xen-plaform,addr=... > > > > I personally would suggest to go for #2. As far I know the platform device is > > only needed if you want attach xenbus devices to the guest (correct?), so > > creating virtual machines without the xen platform device is a valid use case > > and you should allow it. > Looks you recommend we should change current xen platform design, I'm > not sure if something in libxl also need to be modified. Especially, > this may not be compatible with those old xen version. Going for (1) certainly is easier as (2) indeed will need changes in the libxl, and might be tricky to get work with both old+new versions. > And especially, how to guarantee no one occupy 00:02.0 in the future > with auto assign? Creating devices automatically turned out to have a number of problems. So it is very unlikely we'll ever do this again. cheers, Gerd
On Mon, May 19, 2014 at 03:50:31PM +0200, Gerd Hoffmann wrote: > Hi, > > > > Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create pci devices > > > with auto slot assignment, which will occupy slot 2 indeed. > > > Use -device instead to create the devices. > > > > > > > Are you saying we have to create the devices explicitly when we want > > to work IGD vga with passthrough? But how to make sure all user know > > this workable way? Maybe you suggest we should document somewhere. > > libvirt does this unconditionally, because it is a good idea anyway for > a number of reasons. Example: create a machine with three pci devices, > hot-unplug the second, then live-migrate to another machine. The only > way to create the correct config on the target machine is to explicitly > assign slots, otherwise the third pci device ends up in the wrong slot. > > Don't know how the libxl (and xl tool) work. Maybe it does the same > anyway. Maybe it can handle the address assignment transparently for > the user. I'm not sure if libxl itself takes care of this under the hood, but the libvirt libxl driver at least does not deal with persistent PCI address allocation currently. We're pulling the QEMU driver PCI address allocation code out into a shared module, for reuse by libvirt's BHyve driver for BSD, which will make it easy for the libvirt libxl driver to also use it if required too. Regards, Daniel
> -----Original Message----- > From: Michael S. Tsirkin [mailto:mst@redhat.com] > Sent: Monday, May 19, 2014 6:13 PM > To: Chen, Tiejun > Cc: Gerd Hoffmann; anthony.perard@citrix.com; > stefano.stabellini@eu.citrix.com; Kelly.Zytaruk@amd.com; > peter.maydell@linaro.org; xen-devel@lists.xensource.com; Kay, Allen M; > qemu-devel@nongnu.org; jean.guyader@eu.citrix.com; > anthony@codemonkey.ws; Zhang, Yang Z > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: > reserve > 00:02.0 for INTEL IGD > > On Mon, May 19, 2014 at 09:25:19AM +0000, Chen, Tiejun wrote: > > > -----Original Message----- > > > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > > > Sent: Monday, May 19, 2014 2:45 PM > > > To: Chen, Tiejun > > > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > > > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > > > xen-devel@lists.xensource.com; weidong.han@intel.com; Kay, Allen > > > M; qemu-devel@nongnu.org; jean.guyader@eu.citrix.com; > > > anthony@codemonkey.ws; Zhang, Yang Z > > > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: > > > reserve > > > 00:02.0 for INTEL IGD > > > > > > Hi, > > > > > > > + /* > > > > + * Some video bioses and gfx drivers will assume the bdf of > > > > + IGD is > > > 00:02.0. > > > > + * So user need to set it to 00:02.0 in Xen configure file explicitly, > > > > + * otherwise IGD will fail to work. > > > > + */ > > > > + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); > > > > > > That is asking for trouble. Slot 2 is used by the qemu vga cards > > > by default, and for quite a while (before memory api was merged) > > > it even was impossible to change it. libvirt still places the vga > > > card at slot > > > 2 for that reason -> boom. I wouldn't be surprised if you find > > > that assumption in other management libs / apps too. > > > > > > Why do you need that patch in the first place? It should be > > > possible to configure qemu to not occupy slot 2 if you need it > > > that way. Just pass '-vga none' to qemu. Which you probably want > > > anyway if you pass-through a vga to the guest. And explicitly > > > configure a slot (via addr= > > > > I think '-vga none' just guarantees the qemu vga cards doesn't > > occupy 00:02.0, > but this doesn't mean others use this specific slot since in qemu > internal, we always pass -1 to assign a slot automatically to register > a PCI device. So in some cases, we can't get this slot as we expect > since that is already assigned previously before we need this. > > So stop doing this. > Address -1 is a short-cut intended for humans. Are you saying we need remove all auto assigned places like this, piix.c: i440fx_init() if (xen_enabled()) { piix3 = DO_UPCAST(PIIX3State, dev, pci_create_simple_multifunction(b, -1, true, "PIIX3-xen")); pci_bus_irqs(b, xen_piix3_set_irq, xen_pci_slot_get_pirq, piix3, XEN_PIIX_NUM_PIRQS); } else { piix3 = DO_UPCAST(PIIX3State, dev, pci_create_simple_multifunction(b, -1, true, "PIIX3")); > In particular we have no way to guarantee that migration works unless > you specify addresses explicitly. > > > > property) for all your pci devices. Doing it only for the IGD > > > works too if you list the device before any other pci device on > > > the qemu command > line. > > > > So in my test scenario, we can see this information: > > > > PCI: slot 2 function 0 not available for xen-pci-passthrough, in use > > by xen-platform Thanks Tiejun > > I think the best fix is to give priority to devices that supply a specific slot. > Maybe I can extend that bitmap I implemented in patch #1 to do this. But anyway you also need to concern if this is compatible with libxl in xen case. Thanks Tiejun
On Tue, May 20, 2014 at 09:34:23AM +0000, Chen, Tiejun wrote: > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:mst@redhat.com] > > Sent: Monday, May 19, 2014 6:13 PM > > To: Chen, Tiejun > > Cc: Gerd Hoffmann; anthony.perard@citrix.com; > > stefano.stabellini@eu.citrix.com; Kelly.Zytaruk@amd.com; > > peter.maydell@linaro.org; xen-devel@lists.xensource.com; Kay, Allen M; > > qemu-devel@nongnu.org; jean.guyader@eu.citrix.com; > > anthony@codemonkey.ws; Zhang, Yang Z > > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: > > reserve > > 00:02.0 for INTEL IGD > > > > On Mon, May 19, 2014 at 09:25:19AM +0000, Chen, Tiejun wrote: > > > > -----Original Message----- > > > > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > > > > Sent: Monday, May 19, 2014 2:45 PM > > > > To: Chen, Tiejun > > > > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > > > > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > > > > xen-devel@lists.xensource.com; weidong.han@intel.com; Kay, Allen > > > > M; qemu-devel@nongnu.org; jean.guyader@eu.citrix.com; > > > > anthony@codemonkey.ws; Zhang, Yang Z > > > > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: > > > > reserve > > > > 00:02.0 for INTEL IGD > > > > > > > > Hi, > > > > > > > > > + /* > > > > > + * Some video bioses and gfx drivers will assume the bdf of > > > > > + IGD is > > > > 00:02.0. > > > > > + * So user need to set it to 00:02.0 in Xen configure file explicitly, > > > > > + * otherwise IGD will fail to work. > > > > > + */ > > > > > + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); > > > > > > > > That is asking for trouble. Slot 2 is used by the qemu vga cards > > > > by default, and for quite a while (before memory api was merged) > > > > it even was impossible to change it. libvirt still places the vga > > > > card at slot > > > > 2 for that reason -> boom. I wouldn't be surprised if you find > > > > that assumption in other management libs / apps too. > > > > > > > > Why do you need that patch in the first place? It should be > > > > possible to configure qemu to not occupy slot 2 if you need it > > > > that way. Just pass '-vga none' to qemu. Which you probably want > > > > anyway if you pass-through a vga to the guest. And explicitly > > > > configure a slot (via addr= > > > > > > I think '-vga none' just guarantees the qemu vga cards doesn't > > > occupy 00:02.0, > > but this doesn't mean others use this specific slot since in qemu > > internal, we always pass -1 to assign a slot automatically to register > > a PCI device. So in some cases, we can't get this slot as we expect > > since that is already assigned previously before we need this. > > > > So stop doing this. > > Address -1 is a short-cut intended for humans. > > Are you saying we need remove all auto assigned places like this, > > piix.c: i440fx_init() > > if (xen_enabled()) { > piix3 = DO_UPCAST(PIIX3State, dev, > pci_create_simple_multifunction(b, -1, true, "PIIX3-xen")); > pci_bus_irqs(b, xen_piix3_set_irq, xen_pci_slot_get_pirq, > piix3, XEN_PIIX_NUM_PIRQS); > } else { > piix3 = DO_UPCAST(PIIX3State, dev, > pci_create_simple_multifunction(b, -1, true, "PIIX3")); Preferably, these should supply the address explicitly. > > In particular we have no way to guarantee that migration works unless > > you specify addresses explicitly. > > > > > > property) for all your pci devices. Doing it only for the IGD > > > > works too if you list the device before any other pci device on > > > > the qemu command > > line. > > > > > > So in my test scenario, we can see this information: > > > > > > PCI: slot 2 function 0 not available for xen-pci-passthrough, in use > > > by xen-platform Thanks Tiejun > > > > I think the best fix is to give priority to devices that supply a specific slot. > > > > Maybe I can extend that bitmap I implemented in patch #1 to do this. > > But anyway you also need to concern if this is compatible with libxl in xen case. > > Thanks > Tiejun libxl should stop using uto-assignment too.
On Mon, May 19, 2014 at 12:04:14PM +0000, Chen, Tiejun wrote: > > -----Original Message----- > > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > > Sent: Monday, May 19, 2014 7:23 PM > > To: Chen, Tiejun > > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > > xen-devel@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org; > > jean.guyader@eu.citrix.com; anthony@codemonkey.ws; Zhang, Yang Z > > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve > > 00:02.0 for INTEL IGD > > > > Hi, > > > > > I think '-vga none' just guarantees the qemu vga cards doesn't occupy > > > 00:02.0, but this doesn't mean others use this specific slot since in > > > qemu internal, we always pass -1 to assign a slot automatically to > > > register a PCI device. So in some cases, we can't get this slot as we > > > expect since that is already assigned previously before we need this. > > > > Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create pci devices > > with auto slot assignment, which will occupy slot 2 indeed. > > Use -device instead to create the devices. > > > > Are you saying we have to create the devices explicitly when we want to work IGD vga with passthrough? But how to make sure all user know this workable way? Maybe you suggest we should document somewhere. > > > > PCI: slot 2 function 0 not available for xen-pci-passthrough, in use > > > by xen-platform > > > > Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init creates this > > automatically. Two options here IMHO: > > > > (1) Just move it somewhere else explicitly. For example slot 3, or > > make it a southbridge function (say 00:01.7). > > (2) Don't create it automatically, instead expect management add it > > if needed, using -device xen-plaform,addr=... > > > > I personally would suggest to go for #2. As far I know the platform device is > > only needed if you want attach xenbus devices to the guest (correct?), so > > creating virtual machines without the xen platform device is a valid use case > > and you should allow it. > > > > Looks you recommend we should change current xen platform design, I'm not sure if something in libxl also need to be modified. Especially, this may not be compatible with those old xen version. And especially, how to guarantee no one occupy 00:02.0 in the future with auto assign? Hi, Libxl knows how to create a guest without xen-platform, but I think this can work only from QEMU 1.6 (which Xen 4.4 use). So, using the options below with libxl would put the xen-platform device away from the 00:02 slot. xen_platform_pci=0 device_model_args_hvm = [ '-device', 'xen-platform,addr=0x3' ]
> -----Original Message----- > From: Anthony PERARD [mailto:anthony.perard@citrix.com] > Sent: Tuesday, May 20, 2014 10:45 PM > To: Chen, Tiejun > Cc: Gerd Hoffmann; stefano.stabellini@eu.citrix.com; mst@redhat.com; > Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > xen-devel@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org; > anthony@codemonkey.ws; Zhang, Yang Z > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: reserve > 00:02.0 for INTEL IGD > > On Mon, May 19, 2014 at 12:04:14PM +0000, Chen, Tiejun wrote: > > > -----Original Message----- > > > From: Gerd Hoffmann [mailto:kraxel@redhat.com] > > > Sent: Monday, May 19, 2014 7:23 PM > > > To: Chen, Tiejun > > > Cc: anthony.perard@citrix.com; stefano.stabellini@eu.citrix.com; > > > mst@redhat.com; Kelly.Zytaruk@amd.com; peter.maydell@linaro.org; > > > xen-devel@lists.xensource.com; Kay, Allen M; qemu-devel@nongnu.org; > > > jean.guyader@eu.citrix.com; anthony@codemonkey.ws; Zhang, Yang Z > > > Subject: Re: [Qemu-devel] [v2][PATCH 4/8] xen, gfx passthrough: > > > reserve > > > 00:02.0 for INTEL IGD > > > > > > Hi, > > > > > > > I think '-vga none' just guarantees the qemu vga cards doesn't > > > > occupy 00:02.0, but this doesn't mean others use this specific > > > > slot since in qemu internal, we always pass -1 to assign a slot > > > > automatically to register a PCI device. So in some cases, we can't > > > > get this slot as we expect since that is already assigned previously before > we need this. > > > > > > Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally > > > create pci devices with auto slot assignment, which will occupy slot 2 > indeed. > > > Use -device instead to create the devices. > > > > > > > Are you saying we have to create the devices explicitly when we want to work > IGD vga with passthrough? But how to make sure all user know this workable > way? Maybe you suggest we should document somewhere. > > > > > > PCI: slot 2 function 0 not available for xen-pci-passthrough, in > > > > use by xen-platform > > > > > > Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init > > > creates this automatically. Two options here IMHO: > > > > > > (1) Just move it somewhere else explicitly. For example slot 3, or > > > make it a southbridge function (say 00:01.7). > > > (2) Don't create it automatically, instead expect management add it > > > if needed, using -device xen-plaform,addr=... > > > > > > I personally would suggest to go for #2. As far I know the platform > > > device is only needed if you want attach xenbus devices to the guest > > > (correct?), so creating virtual machines without the xen platform > > > device is a valid use case and you should allow it. > > > > > > > Looks you recommend we should change current xen platform design, I'm not > sure if something in libxl also need to be modified. Especially, this may not be > compatible with those old xen version. And especially, how to guarantee no one > occupy 00:02.0 in the future with auto assign? > > Hi, > > Libxl knows how to create a guest without xen-platform, but I think this can > work only from QEMU 1.6 (which Xen 4.4 use). > > So, using the options below with libxl would put the xen-platform device away > from the 00:02 slot. > xen_platform_pci=0 > device_model_args_hvm = [ '-device', 'xen-platform,addr=0x3' ] > I added these two lines in domU's configuration file, but failed: tchen0@tchen0-linux:~/workspace$ sudo xl cr domu-cfg Parsing config from domu-cfg libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set libxl: error: libxl_create.c:1277:domcreate_attach_pci: libxl_device_pci_add failed: -3 tchen0@tchen0-linux:~/workspace$ cat /var/log/xen/qemu-dm-HVM.log char device redirected to /dev/pts/49 (label serial0) qemu: terminating on signal 1 from pid 3117 Anything else I'm still missing? Or this mean this way can't work based on the latest qemu/xen? Thanks Tiejun
On 2014/5/19 19:22, Gerd Hoffmann wrote: > Hi, > >> I think '-vga none' just guarantees the qemu vga cards doesn't occupy >> 00:02.0, but this doesn't mean others use this specific slot since in >> qemu internal, we always pass -1 to assign a slot automatically to >> register a PCI device. So in some cases, we can't get this slot as we >> expect since that is already assigned previously before we need this. > > Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create > pci devices with auto slot assignment, which will occupy slot 2 indeed. > Use -device instead to create the devices. > >> PCI: slot 2 function 0 not available for xen-pci-passthrough, in use >> by xen-platform > > Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init creates > this automatically. Two options here IMHO: > > (1) Just move it somewhere else explicitly. For example slot 3, or > make it a southbridge function (say 00:01.7). > (2) Don't create it automatically, instead expect management add it > if needed, using -device xen-plaform,addr=... > Gerd, Sorry I return this discussion again. As we discussed here, we should never use -vga xxx to avoid occupying slot 2. Instead, we will just use -device to create that emulated vga device as you said like this: -device VGA,vgamem_mb=8,addr=0x4 But looks this may issue another problem. That is we can't see anything until the vga driver is initialized. I means if we pass `-device VGA,vgamem_mb=8,addr=0x4', qemu doesn't expose any vga interface to BIOS. Right? Or I'm still missing something. Thanks Tiejun
On 06/24/14 22:49, Chen, Tiejun wrote: > On 2014/5/19 19:22, Gerd Hoffmann wrote: >> Hi, >> >>> I think '-vga none' just guarantees the qemu vga cards doesn't occupy >>> 00:02.0, but this doesn't mean others use this specific slot since in >>> qemu internal, we always pass -1 to assign a slot automatically to >>> register a PCI device. So in some cases, we can't get this slot as we >>> expect since that is already assigned previously before we need this. >> >> Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create >> pci devices with auto slot assignment, which will occupy slot 2 indeed. >> Use -device instead to create the devices. >> >>> PCI: slot 2 function 0 not available for xen-pci-passthrough, in use >>> by xen-platform >> >> Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init creates >> this automatically. Two options here IMHO: >> >> (1) Just move it somewhere else explicitly. For example slot 3, or >> make it a southbridge function (say 00:01.7). >> (2) Don't create it automatically, instead expect management add it >> if needed, using -device xen-plaform,addr=... >> > > Gerd, > > Sorry I return this discussion again. > > As we discussed here, we should never use -vga xxx to avoid occupying > slot 2. Instead, we will just use -device to create that emulated vga > device as you said like this: > > -device VGA,vgamem_mb=8,addr=0x4 > > But looks this may issue another problem. That is we can't see > anything until the vga driver is initialized. I means if we pass > `-device VGA,vgamem_mb=8,addr=0x4', qemu doesn't expose any vga > interface to BIOS. Right? Or I'm still missing something. > I know for Xen that tools/firmware/hvmloader/acpi/dsdt.asl also needs to change: /* Make cirrues VGA S3 suspend/resume work in Windows XP/2003 */ Device (VGA) { - Name (_ADR, 0x00020000) + // Address of the VGA (device F function 0) + Name (_ADR, 0x000F0000) is what I have for: -device VGA,vgamem_mb=8,addr=0xF.0x0 I am not sure, but think that QEMU without Xen does this acpi adjustment at run time. I also change seabios's config to include more VGA support but not sure it is needed. -Don Slutz > Thanks > Tiejun >
On 2014/6/26 7:04, Slutz, Donald Christopher wrote: > On 06/24/14 22:49, Chen, Tiejun wrote: >> On 2014/5/19 19:22, Gerd Hoffmann wrote: >>> Hi, >>> >>>> I think '-vga none' just guarantees the qemu vga cards doesn't occupy >>>> 00:02.0, but this doesn't mean others use this specific slot since in >>>> qemu internal, we always pass -1 to assign a slot automatically to >>>> register a PCI device. So in some cases, we can't get this slot as we >>>> expect since that is already assigned previously before we need this. >>> >>> Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create >>> pci devices with auto slot assignment, which will occupy slot 2 indeed. >>> Use -device instead to create the devices. >>> >>>> PCI: slot 2 function 0 not available for xen-pci-passthrough, in use >>>> by xen-platform >>> >>> Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init creates >>> this automatically. Two options here IMHO: >>> >>> (1) Just move it somewhere else explicitly. For example slot 3, or >>> make it a southbridge function (say 00:01.7). >>> (2) Don't create it automatically, instead expect management add it >>> if needed, using -device xen-plaform,addr=... >>> >> >> Gerd, >> >> Sorry I return this discussion again. >> >> As we discussed here, we should never use -vga xxx to avoid occupying >> slot 2. Instead, we will just use -device to create that emulated vga >> device as you said like this: >> >> -device VGA,vgamem_mb=8,addr=0x4 >> >> But looks this may issue another problem. That is we can't see >> anything until the vga driver is initialized. I means if we pass >> `-device VGA,vgamem_mb=8,addr=0x4', qemu doesn't expose any vga >> interface to BIOS. Right? Or I'm still missing something. >> > > I know for Xen that > > tools/firmware/hvmloader/acpi/dsdt.asl > > also needs to change: > > > /* Make cirrues VGA S3 suspend/resume work in Windows > XP/2003 */ > Device (VGA) > { > - Name (_ADR, 0x00020000) > + // Address of the VGA (device F function 0) > + Name (_ADR, 0x000F0000) > > > is what I have for: > > -device VGA,vgamem_mb=8,addr=0xF.0x0 > Do you mean we need to sync devfn with the passed address to work the emulated VGA before the real graphic device driver is called? Thanks Tiejun > I am not sure, but think that QEMU without Xen does this acpi > adjustment at run time. > > > I also change seabios's config to include more VGA support but > not sure it is needed. > > -Don Slutz > >> Thanks >> Tiejun >>
On 2014/6/26 10:00, Chen, Tiejun wrote: > On 2014/6/26 7:04, Slutz, Donald Christopher wrote: >> On 06/24/14 22:49, Chen, Tiejun wrote: >>> On 2014/5/19 19:22, Gerd Hoffmann wrote: >>>> Hi, >>>> >>>>> I think '-vga none' just guarantees the qemu vga cards doesn't occupy >>>>> 00:02.0, but this doesn't mean others use this specific slot since in >>>>> qemu internal, we always pass -1 to assign a slot automatically to >>>>> register a PCI device. So in some cases, we can't get this slot as we >>>>> expect since that is already assigned previously before we need this. >>>> >>>> Yes, -vga, -net nic, -drive if=scsi (maybe more) can internally create >>>> pci devices with auto slot assignment, which will occupy slot 2 indeed. >>>> Use -device instead to create the devices. >>>> >>>>> PCI: slot 2 function 0 not available for xen-pci-passthrough, in use >>>>> by xen-platform >>>> >>>> Ah, the xen platform device. /me looks. Ah, pc_xen_hvm_init creates >>>> this automatically. Two options here IMHO: >>>> >>>> (1) Just move it somewhere else explicitly. For example slot 3, or >>>> make it a southbridge function (say 00:01.7). >>>> (2) Don't create it automatically, instead expect management add it >>>> if needed, using -device xen-plaform,addr=... >>>> >>> >>> Gerd, >>> >>> Sorry I return this discussion again. >>> >>> As we discussed here, we should never use -vga xxx to avoid occupying >>> slot 2. Instead, we will just use -device to create that emulated vga >>> device as you said like this: >>> >>> -device VGA,vgamem_mb=8,addr=0x4 >>> >>> But looks this may issue another problem. That is we can't see >>> anything until the vga driver is initialized. I means if we pass >>> `-device VGA,vgamem_mb=8,addr=0x4', qemu doesn't expose any vga >>> interface to BIOS. Right? Or I'm still missing something. >>> >> >> I know for Xen that >> >> tools/firmware/hvmloader/acpi/dsdt.asl >> >> also needs to change: >> >> >> /* Make cirrues VGA S3 suspend/resume work in Windows >> XP/2003 */ >> Device (VGA) >> { >> - Name (_ADR, 0x00020000) >> + // Address of the VGA (device F function 0) >> + Name (_ADR, 0x000F0000) >> With this change I still didn't see anything. Thanks Tiejun >> >> is what I have for: >> >> -device VGA,vgamem_mb=8,addr=0xF.0x0 >> > > Do you mean we need to sync devfn with the passed address to work the > emulated VGA before the real graphic device driver is called? > > Thanks > Tiejun > >> I am not sure, but think that QEMU without Xen does this acpi >> adjustment at run time. >> >> >> I also change seabios's config to include more VGA support but >> not sure it is needed. >> >> -Don Slutz >> >>> Thanks >>> Tiejun >>> > > >
On 06/26/14 04:23, Chen, Tiejun wrote: > On 2014/6/26 10:00, Chen, Tiejun wrote: >> On 2014/6/26 7:04, Slutz, Donald Christopher wrote: >>> On 06/24/14 22:49, Chen, Tiejun wrote: >>>> On 2014/5/19 19:22, Gerd Hoffmann wrote: >>>>> Hi, >>>>> >>>>> >>>> >>>> Gerd, >>>> >>>> Sorry I return this discussion again. >>>> >>>> As we discussed here, we should never use -vga xxx to avoid occupying >>>> slot 2. Instead, we will just use -device to create that emulated vga >>>> device as you said like this: >>>> >>>> -device VGA,vgamem_mb=8,addr=0x4 >>>> >>>> But looks this may issue another problem. That is we can't see >>>> anything until the vga driver is initialized. I means if we pass >>>> `-device VGA,vgamem_mb=8,addr=0x4', qemu doesn't expose any vga >>>> interface to BIOS. Right? Or I'm still missing something. >>>> >>> QEMU does not directly expose any vga interface to BIOS (SeaBIOS in my case). However SeaBIOS searches for a vga device on the PCI Host bridge. And my testing is showing that it finds it. (d12) Scan for VGA option rom (d12) Running option rom at c000:0003 (XEN) stdvga.c:147:d12v0 entering stdvga and caching modes >>> I know for Xen that >>> >>> tools/firmware/hvmloader/acpi/dsdt.asl >>> >>> also needs to change: >>> >>> >>> /* Make cirrues VGA S3 suspend/resume work in Windows >>> XP/2003 */ >>> Device (VGA) >>> { >>> - Name (_ADR, 0x00020000) >>> + // Address of the VGA (device F function 0) >>> + Name (_ADR, 0x000F0000) >>> > > With this change I still didn't see anything. > This does not match with what I see. Looks like linux does not care about the acpi data. Using xen: ddb4aa5, qemu: 8589744, and seabios: e51488c and GRUB_CMDLINE_XEN="dom0_mem=2G loglvl=all guest_loglvl=all console_timestamps=1 com1=9600,8n1 console=com1 apic_verbosity=verbose crashkernel=256M@256M no-cpuidle" Config file (/home/don/P-1-5.list0.xfg): dcs-xen-54:~>cat P-1-5.list0.xfg builder = "hvm" cpu_weight = 128 cpus = [ 5, ] vga = "none" videoram = 8 device_model_args_hvm = [ "-monitor", "pty", "-boot", "menu=on", "-device", "VGA,vgamem_mb=8,addr=0x4", "-device", "e1000,id=nic0,netdev=net0,mac=00:0c:29:a0:a9:2c,addr=0x5.0x0", "-netdev", "type=tap,id=net0,ifname=vif9.0-emu,script=/etc/qemu-ifup,downscript=no", "-device", "xen-platform,addr=0x6.0x0", ] disk = [ "/home/don/qemu-img/P-1-5-disk.raw,,hda", ] device_model_version = "qemu-xen" maxmem = 3072 maxvcpus = 1 memory = 3072 name = "P-1-5" serial = "pty" tsc_mode = "native_paravirt" uuid = "18cf5fd0-e564-49c4-b63f-e6c3c23b1294" vcpus = 1 viridian = 0 xen_platform_pci = 0 [root@dcs-xen-54 ~]# xl cre -p -V /home/don/P-1-5.list0.xfg Gives me a vncviewer screen that says: Guest has not initialized the display (yet). [root@dcs-xen-54 ~]# xl unpause 12 Adds the following ([root@dcs-xen-54 ~]# xl dmesg): (d12) HVM Loader (d12) Detected Xen v4.5-unstable (d12) Xenbus rings @0xfeffc000, event channel 1 (d12) System requested SeaBIOS (d12) CPU speed is 2400 MHz (d12) Relocating guest memory for lowmem MMIO space disabled (XEN) irq.c:270: Dom12 PCI link 0 changed 0 -> 5 (d12) PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:270: Dom12 PCI link 1 changed 0 -> 10 (d12) PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:270: Dom12 PCI link 2 changed 0 -> 11 (d12) PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:270: Dom12 PCI link 3 changed 0 -> 5 (d12) PCI-ISA link 3 routed to IRQ5 (d12) pci dev 01:3 INTA->IRQ10 (d12) pci dev 05:0 INTA->IRQ10 (d12) pci dev 06:0 INTA->IRQ11 (d12) No RAM in high memory; setting high_mem resource base to 100000000 (d12) pci dev 06:0 bar 14 size 001000000: 0f0000008 (d12) pci dev 04:0 bar 10 size 000800000: 0f1000008 (d12) pci dev 05:0 bar 30 size 000040000: 0f1800000 (d12) pci dev 05:0 bar 10 size 000020000: 0f1840000 (d12) pci dev 04:0 bar 30 size 000010000: 0f1860000 (d12) pci dev 04:0 bar 18 size 000001000: 0f1870000 (d12) pci dev 06:0 bar 10 size 000000100: 00000c001 (d12) pci dev 05:0 bar 14 size 000000040: 00000c101 (d12) pci dev 01:1 bar 20 size 000000010: 00000c141 (d12) Multiprocessor initialisation: (d12) - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done. (d12) Testing HVM environment: (d12) - REP INSB across page boundaries ... passed (d12) - GS base MSRs and SWAPGS ... passed (d12) Passed 2 of 2 tests (d12) Writing SMBIOS tables ... (d12) Loading SeaBIOS ... (d12) Creating MP tables ... (d12) Loading ACPI ... (d12) vm86 TSS at fc00a180 (d12) BIOS map: (d12) 10000-100d3: Scratch space (d12) c0000-fffff: Main BIOS (d12) E820 table: (d12) [00]: 00000000:00000000 - 00000000:000a0000: RAM (d12) HOLE: 00000000:000a0000 - 00000000:000c0000 (d12) [01]: 00000000:000c0000 - 00000000:00100000: RESERVED (d12) [02]: 00000000:00100000 - 00000000:bf800000: RAM (d12) HOLE: 00000000:bf800000 - 00000000:fc000000 (d12) [03]: 00000000:fc000000 - 00000001:00000000: RESERVED (d12) Invoking SeaBIOS ... (d12) SeaBIOS (version rel-1.7.5-0-ge51488c-20140626_113926-dcs-xen-54) (d12) (d12) Found Xen hypervisor signature at 40000000 (d12) Running on QEMU (i440fx) (d12) xen: copy e820... (d12) Relocating init from 0x000df629 to 0xbf7ae600 (size 71995) (d12) CPU Mhz=2400 (d12) Found 7 PCI devices (max PCI bus is 00) (d12) Allocated Xen hypercall page at bf7ff000 (d12) Detected Xen v4.5-unstable (d12) xen: copy BIOS tables... (d12) Copying SMBIOS entry point from 0x00010010 to 0x000f0f50 (d12) Copying MPTABLE from 0xfc001140/fc001150 to 0x000f0e70 (d12) Copying PIR from 0x00010030 to 0x000f0df0 (d12) Copying ACPI RSDP from 0x000100b0 to 0x000f0dc0 (d12) Using pmtimer, ioport 0xb008 (d12) Scan for VGA option rom (d12) Running option rom at c000:0003 (XEN) stdvga.c:147:d12v0 entering stdvga and caching modes (d12) pmm call arg1=0 (d12) Turning on vga text mode console (d12) SeaBIOS (version rel-1.7.5-0-ge51488c-20140626_113926-dcs-xen-54) (d12) Machine UUID 18cf5fd0-e564-49c4-b63f-e6c3c23b1294 (d12) All threads complete. (d12) Found 0 lpt ports (d12) Found 1 serial ports (d12) ATA controller 1 at 1f0/3f4/0 (irq 14 dev 9) (d12) ATA controller 2 at 170/374/0 (irq 15 dev 9) (d12) ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (8192 MiBytes) (d12) Searching bootorder for: /pci@i0cf8/*@1,1/drive@0/disk@0 (d12) PS2 keyboard initialized (d12) All threads complete. (d12) Scan for option roms (d12) Running option rom at c980:0003 (d12) pmm call arg1=1 (d12) pmm call arg1=0 (d12) pmm call arg1=1 (d12) pmm call arg1=0 (d12) Searching bootorder for: /pci@i0cf8/*@5 (d12) (d12) Press F12 for boot menu. (d12) (d12) Select boot device: (d12) (d12) 1. ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (8192 MiBytes) (d12) 2. iPXE (PCI 00:05.0) And the VGA screen has the SeaBIOS messages: SeaBIOS (version rel-1.7.5-0-ge51488c-20140626_113926-dcs-xen-54) Machine UUID 18cf5fd0-e564-49c4-b63f-e6c3c23b1294 iPXE (http://ipxe.org) 00:05.0 C980 PCI2.10 PnP PMM+BF79C090+BF6FC090 C980 Press F12 for boot menu. Select boot device: 1. ata0-0: QEMU HARDDISK ATA-7 Hard-Disk (8192 MiBytes) 2. iPXE (PCI 00:05.0) The line (from above): (d12) Turning on vga text mode console allows me to use f12 in seabios which is why the guest is stopped waiting for a boot device selection. In the guest (after boot): [root@P-1-5 ~]# lspci 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:04.0 VGA compatible controller: Technical Corp. Unknown device 1111 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:06.0 Class ff80: XenSource, Inc. Xen Platform Device (rev 01) Hope all this helps. -Don Slutz > Thanks > Tiejun > >>> >>> is what I have for: >>> >>> -device VGA,vgamem_mb=8,addr=0xF.0x0 >>> >> >> Do you mean we need to sync devfn with the passed address to work the >> emulated VGA before the real graphic device driver is called? >> >> Thanks >> Tiejun >> >>> I am not sure, but think that QEMU without Xen does this acpi >>> adjustment at run time. >>> >>> >>> I also change seabios's config to include more VGA support but >>> not sure it is needed. >>> >>> -Don Slutz >>> >>>> Thanks >>>> Tiejun >>>> >> >> >>
Hi, > >>> /* Make cirrues VGA S3 suspend/resume work in Windows > >>> XP/2003 */ > >>> Device (VGA) > >>> { > >>> - Name (_ADR, 0x00020000) > >>> + // Address of the VGA (device F function 0) > >>> + Name (_ADR, 0x000F0000) > >>> > > > > With this change I still didn't see anything. > > > > This does not match with what I see. > > Looks like linux does not care about the acpi data. Using The acpi data doesn't matter at all for the boot screen, the vgabios doesn't look at it. > (d12) Scan for VGA option rom > (d12) Running option rom at c000:0003 seabios loaded+initialized the vgabios (from the pci rom bar of the vga device). Which slot the vga is installed at should not matter at all. seabios scans the pci bus and should find the vga with no problems no matter where it is. > (XEN) stdvga.c:147:d12v0 entering stdvga and caching modes Seems to have worked fine ;) > (d12) pmm call arg1=0 > (d12) Turning on vga text mode console > (d12) SeaBIOS (version rel-1.7.5-0-ge51488c-20140626_113926-dcs-xen-54) At this point you should see the seabios banner at the vga screen. > And the VGA screen has the SeaBIOS messages: > > SeaBIOS (version rel-1.7.5-0-ge51488c-20140626_113926-dcs-xen-54) > Machine UUID 18cf5fd0-e564-49c4-b63f-e6c3c23b1294 As it should be. Now the questions is why it doesn't work for Tiejun ... Anything in the logs? cheers, Gerd
On 2014/6/30 17:29, Gerd Hoffmann wrote: > Hi, > >>>>> /* Make cirrues VGA S3 suspend/resume work in Windows >>>>> XP/2003 */ >>>>> Device (VGA) >>>>> { >>>>> - Name (_ADR, 0x00020000) >>>>> + // Address of the VGA (device F function 0) >>>>> + Name (_ADR, 0x000F0000) >>>>> >>> >>> With this change I still didn't see anything. >>> >> >> This does not match with what I see. >> >> Looks like linux does not care about the acpi data. Using > > The acpi data doesn't matter at all for the boot screen, the vgabios > doesn't look at it. > >> (d12) Scan for VGA option rom >> (d12) Running option rom at c000:0003 > > seabios loaded+initialized the vgabios (from the pci rom bar of the vga > device). Which slot the vga is installed at should not matter at all. > seabios scans the pci bus and should find the vga with no problems no > matter where it is. > >> (XEN) stdvga.c:147:d12v0 entering stdvga and caching modes > > Seems to have worked fine ;) > >> (d12) pmm call arg1=0 >> (d12) Turning on vga text mode console >> (d12) SeaBIOS (version rel-1.7.5-0-ge51488c-20140626_113926-dcs-xen-54) > > At this point you should see the seabios banner at the vga screen. > >> And the VGA screen has the SeaBIOS messages: >> >> SeaBIOS (version rel-1.7.5-0-ge51488c-20140626_113926-dcs-xen-54) >> Machine UUID 18cf5fd0-e564-49c4-b63f-e6c3c23b1294 > > As it should be. > > Now the questions is why it doesn't work for Tiejun ... Gerd and Don, Thanks for your information. But I have no time to validate this configuration now, I will update this as soon as I try Don's config file. Thanks again. Tiejun > Anything in the logs? > > cheers, > Gerd > > > >
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c index ffdc853..b6f49bd 100644 --- a/hw/pci-host/piix.c +++ b/hw/pci-host/piix.c @@ -329,6 +329,14 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, s = PCI_HOST_BRIDGE(dev); b = pci_bus_new(dev, NULL, pci_address_space, address_space_io, 0, TYPE_PCI_BUS); + + /* + * Some video bioses and gfx drivers will assume the bdf of IGD is 00:02.0. + * So user need to set it to 00:02.0 in Xen configure file explicitly, + * otherwise IGD will fail to work. + */ + pci_reserve_pci_devfn(b, PCI_DEVFN(2, 0)); + s->bus = b; object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev), NULL); qdev_init_nofail(dev);