Hi Stefano, I noticed that the MSI-INTx translation doesn''t work in recent xen-unstable. After some investigation, it tracks down to the change in changeset 20348. And with the fix from 20397, the pci devclass is now created at the time of the first pci device assignment, either it''s booting device or hotplug device. However, one of the problem is that pci devclass provides pci global parameters, for example, pci_msitranslate and pci_power_mgmt. The device model used to get the value of these global parameters at init time, but now, it won''t see anything since the pci block in xenstore doesn''t exist at that time. So the problem now is that these parameters are bypassed and the guest can''t benefit from it. I can add some flags in qemu similar to first_dev, but that looks a little weird. I''m not very familiar with stubdom initialization, so I''d like to know how the pci devclass is used in the stubdom, and why there is some circular dependency? Thanks, Qing _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2 Dec 2009, Qing He wrote:> Hi Stefano, > I noticed that the MSI-INTx translation doesn''t work in > recent xen-unstable. After some investigation, it tracks down to > the change in changeset 20348. And with the fix from 20397, the > pci devclass is now created at the time of the first pci device > assignment, either it''s booting device or hotplug device. > > However, one of the problem is that pci devclass provides > pci global parameters, for example, pci_msitranslate and > pci_power_mgmt. The device model used to get the value of these > global parameters at init time, but now, it won''t see anything > since the pci block in xenstore doesn''t exist at that time. > So the problem now is that these parameters are bypassed and > the guest can''t benefit from it. I can add some flags in qemu > similar to first_dev, but that looks a little weird.If I am not mistaken xend keeps an internal record of those flags so it could use that info to set per device default flags: xenstore-write opts-$DEVNUM msitranslate=$MSITRANS,power_mgmt=$POWERMGM> I''m not very familiar with stubdom initialization, so > I''d like to know how the pci devclass is used in the stubdom, > and why there is some circular dependency? >The problem was introduced by 19679, "xend: hot-plug PCI devices at boot-time": - xend is creating the guest domain - as part of this process xend forks and execs stubdom-dm - afterward xend hotplugs a pci device into the guest - then waits for the device model to say it is done (signalDeviceModel) but this never happens because stubdom-dm is trying to create the stubdom but xend hasn''t replied yet because is busy with the guest domain. This problem doesn''t exist anymore. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, 2009-12-02 at 19:30 +0800, Stefano Stabellini wrote:> If I am not mistaken xend keeps an internal record of those flags so it > could use that info to set per device default flags: > > xenstore-write opts-$DEVNUM msitranslate=$MSITRANS,power_mgmt=$POWERMGMThat looks good, just one question, if pci devclass is not created, can these global parameters be persistent across save/restore and live migration?> The problem was introduced by 19679, "xend: hot-plug PCI devices at > boot-time": > > - xend is creating the guest domain > - as part of this process xend forks and execs stubdom-dm > - afterward xend hotplugs a pci device into the guest > - then waits for the device model to say it is done (signalDeviceModel) > but this never happens because stubdom-dm is trying to create the > stubdom but xend hasn''t replied yet because is busy with the guest > domain. > > This problem doesn''t exist anymore.If it doesn''t exist anymore, do you think it''s easier to revert to old scheme? (Always creating pci devclass). Thanks, Qing _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 4 Dec 2009, Qing He wrote:> On Wed, 2009-12-02 at 19:30 +0800, Stefano Stabellini wrote: > > If I am not mistaken xend keeps an internal record of those flags so it > > could use that info to set per device default flags: > > > > xenstore-write opts-$DEVNUM msitranslate=$MSITRANS,power_mgmt=$POWERMGM > > That looks good, just one question, if pci devclass is not created, > can these global parameters be persistent across save/restore and live > migration?Yes, they can. Actually xend saves and restores them already.> > If it doesn''t exist anymore, do you think it''s easier to revert to old > scheme? (Always creating pci devclass). >It is possible to revert to the old scheme as long as you don''t try to use qemu\stubdom to hotplug the devices at boot time (before 19679). BTW in libxenlight would be easy to achieve both, but at the moment we are just doing the same thing xend does. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel