Stefano Stabellini writes ("Re: [Xen-devel] Re: Reuse QEMU image for HVM?"):
> There are not many differences in the device emulation between qemu
> mainstream and xen now.
> I think Windows would complain even if you try with a brand new qemu
> compiled from svn, because your image is probably too old (created with
> a too old qemu).
The real problem is probably that Xen's qemu reports various different
ids in its PCI devices: the `subsystem vendor' is set to a value
indicating Xensource. In theory it would be possible to make a qemu
which did the same, but at the moment it's not that easy because the
changes to do this aren't easily separated out from the other changes
in our tree.
On the qemu upstream list it has been proposed that there should be a
single place where the subsystem vendor is controlled, and if that
patch were accepted it would make the difference between us and
upstream smaller and of course make it easier to make an upstream qemu
simulate more like Xen's.
The difference in subsystem vendors between the trees needs to remain,
though, because it's used for example by PV drivers to identify which
`native' devices need to be masked. So for example if the system has
a pci ne2k ethernet card reporting subsystem vendor Xensource, and the
Xen PV driver in the guest has successfully discovered the
corresponding PV vif, it needs to prevent the ordinary guest's ne2k
driver from binding to the `ne2k' or the same interface will turn up
twice. In the case of disks seeing the same disk via different paths
can cause even more serious problems.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel