This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: xenstore pci global parameters

To: Qing He <qing.he@xxxxxxxxx>
Subject: [Xen-devel] Re: xenstore pci global parameters
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Wed, 2 Dec 2009 11:30:15 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 02 Dec 2009 03:27:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20091202081028.GA15730@ub-qhe2>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20091202081028.GA15730@ub-qhe2>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
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

- 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

This problem doesn't exist anymore.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>