> same driver, of course, and live happily ever after. Also, we considered > using Sun PCI subsystem IDs (as we do on our actual hardware), but > figured that it would be better to use the XenSource ids, so that all > Xen-based products out there can use eachothers virtual machines with > minimal hassle.On the Linux side I''d also prefer the Xen identifiers as it means we can reliably identify emulated hardware which can now and then be useful when debugging reports or if the emulation is quirky. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
[sorry if you get this twice, I had an email hiccup sending this] Hi folks, In our SVVP testing, we noticed that the Microsoft HCT requires that PCI subsystem IDs are set for all PCI devices. Meaning that for Xen to be a compliant virtualization platform, qemu-dm must have these set for all devices. A comment in tools/ioemu/hw/xen_platform.c notes that this is a known issue, and other source files show that the intent is to use the XenSource ID (0x5853) for the subsystem vendor ID, and 0x0001 for the subsystem id throughout. But, this isn''t done across the board (e.g. the PIIX bridge devices don''t have these IDs). This makes the Microsoft HCT fail. Attached is a patch that makes pci_register_device initialize these values with the 0x5853/0x0001 defaults, and removes the explicit inits of these values in the various devices. A few issues that are worthy of discussion: since Windows use the subsystem IDs in its device tree, Windows systems will come up with ''found new hardware'' after this patch. But, they will just reload the same driver, of course, and live happily ever after. Also, we considered using Sun PCI subsystem IDs (as we do on our actual hardware), but figured that it would be better to use the XenSource ids, so that all Xen-based products out there can use eachothers virtual machines with minimal hassle. - Frank _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 20/8/08 18:04, "Frank van der Linden" <Frank.Vanderlinden@Sun.COM> wrote:> But, this isn''t done across the board (e.g. the PIIX bridge devices > don''t have these IDs). This makes the Microsoft HCT fail. > > Attached is a patch that makes pci_register_device initialize these > values with the 0x5853/0x0001 defaults, and removes the explicit inits > of these values in the various devices. > > A few issues that are worthy of discussion: since Windows use the > subsystem IDs in its device tree, Windows systems will come up with > ''found new hardware'' after this patch. But, they will just reload the > same driver, of course, and live happily ever after. Also, we considered > using Sun PCI subsystem IDs (as we do on our actual hardware), but > figured that it would be better to use the XenSource ids, so that all > Xen-based products out there can use eachothers virtual machines with > minimal hassle.This should be a patch against the qemu-xen-unstable.git repository. This would only possibly get applied on the 3.4 branch and we will be deleting the old qemu tree from the Xen repository very soon when that branch opens. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Aug 20, 2008 at 06:15:26PM +0100, Keir Fraser wrote:> This should be a patch against the qemu-xen-unstable.git repository. This > would only possibly get applied on the 3.4 branch and we will be deleting > the old qemu tree from the Xen repository very soon when that branch opens.How soon will you delete it? I''m asking because xen/ia64 hasn''t supported ioemu-remote yet, so xen/ia64 developers need some time to address it before deleting. -- yamahata _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21/8/08 03:15, "Isaku Yamahata" <yamahata@valinux.co.jp> wrote:> On Wed, Aug 20, 2008 at 06:15:26PM +0100, Keir Fraser wrote: > >> This should be a patch against the qemu-xen-unstable.git repository. This >> would only possibly get applied on the 3.4 branch and we will be deleting >> the old qemu tree from the Xen repository very soon when that branch opens. > > How soon will you delete it? > I''m asking because xen/ia64 hasn''t supported ioemu-remote yet, > so xen/ia64 developers need some time to address it before deleting.We''d like to get it deleted within a few weeks. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel