as distributed in portage, kvm provides (and builds) only the userspace part relying in a user to provide his own kernel module (through the confusing use of the haskernel USE flag) or in the kernel module distributed with the kernel package (the default and only option available from portage now, as there is no kvm kernel module package). as shown in BUG231659 one of those patches is the same that used to be provided by the "sajinet" external overlay in : http://tapir.sajinet.com.pe/gentoo/portage/app-emulation/kvm/files/kvm-57-kernel-longmode.patch but is not getting applied to the right place, as it is useless in a kvm package that doesn't provide a kvm kernel module like the one now in the tree and is resulting in broken 64bit Solaris guests. Reproducible: Always Steps to Reproduce: 1. emerge -DNvu kvm 2. kvm -m 512 -net user -net nic,model=e1000 64bitsolaris.img 3. Actual Results: VM fails to boot and restart with a GP fault error in the host dmesg Expected Results: VM booting as it used to when using the "unofficial" kvm package that this "official" one seems to be based on the kvm package shouldn't have a patch that doesn't have any effect and if relying in the gentoo kernel is to be expected, then should push this fix to the gentoo kernel as suggested by BUG231659. as an alternative, a kvm module could be generated from the kvm sources and patched, either as part of this package (as was done in the "unofficial" package) or by doing it through a different package that will provide instead for the missing "USE=haskernel" case.
additionally the following changes might be needed in the ebuild as it is being distributed officially : *) no need to inherit linux-mod, since no kernel module is being generated *) no need to restrict "mirror" since an official package is mirrored *) probably a good idea to include keywords: "-ia64 -ppc -ppc64" as they are supported upstream and will be useful to stabilize in gentoo. *) no need to send "--disable-gcc-check" as that is the default since kvm-70 *) in the post install message it should reference to the kvm-ifup script since that is the name used in this package as it was renamed at install time.
Created attachment 160291 [details, diff] a patch that implements the suggested changes to the ebuild removes 2 patches that are ineffective in the current setup and that should be removed from files as well. the second patch eliminated corresponds to fixes to the kvm script that is not being distributes, and was never meant for distribution as is used only upstream for automated testing.
some of the changes suggested as errors in the ebuild already implemented for kvm-71-r2, still the core issues identified by this bug remaining : * a patch for the kernel distributed and applied with no effect * inconsistent inherit list with the fact that no kernel module is generated as well as some of the other observed issues like : * disable-gcc-check still added to configure even if it is no longer needed * no work being done to include ia64, ppc or s390 which are also supported upstream
- The patch causes no problems. I may remove it, I may not, see below. - We need at least linux-info. linux-mod provides that, and doesn't cause problems. I may remove this, I may not, see below. - The disable-gcc-check can be cleaned up at any time. Again, it causes no problems. - I have no ppc, ia64, or s390. I therefore cannot support them. If some other dev wants to step in and help support them, fine. We (gentoo) do not add keywords to things merely because upstream claims support. If you feel keywording for some arch is desired, file a keyword bug with that arch. I'm considering putting the kernel module back (it was there in the overlay for a while). I haven't decided yet. Until I do, there's not a lot of point in changing the ebuild for things related to the module that don't cause any problems.
BTW: kvm-72.tar.gz is out!
85 both has kernel modules,and is split into kernel/userspace parts. This bug isn't relevant anymore, I believe.
