Hi,
as I outlined before the kernel is already fixed.
E.g. if testing install from 16.04.2 there kernel in there already "tolerates"
it enough to work fine.
If that was due to the patches you referred or others I don't know. But
it is not important, as the remaining question was to fix qemu in a way
to work with older guests (of any sort).
So my questions are:
@Bugproxy - do we stick with qemu-part as-is and leave it as it is (set to
won't fix)?
@Rafael Folco (from the dup bug) - would that be acceptable for you since newer
Kernel versions (e.g. the 16.04.2 we both tested) work?
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Milestone: None => ubuntu-16.04.2
** Changed in: linux (Ubuntu)
Status: New => Fix Released
** No longer affects: linux (Ubuntu Xenial)
** No longer affects: linux (Ubuntu Yakkety)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1664622
Title:
qemu: Missing transaction memory advertisement
Status in linux package in Ubuntu:
Fix Released
Status in qemu package in Ubuntu:
Fix Released
Status in qemu source package in Xenial:
Incomplete
Status in qemu source package in Yakkety:
Incomplete
Bug description:
[Impact]
* The non HW assisted virtualization (kvm-pr) on PowerPC announces
support for the Transactional memory feature but does not fully
support it. Due to that guests crash.
* The fix essentially takes away the TM feature by default and only
enables it incertain cases where it is correct (right HW and recent
KVM-HV implementation)
[Test Case]
* Repro
1. install uvtool-libvirt in Host
2. uvt-simplestreams-libvirt sync --source
http://cloud-images.ubuntu.com/daily arch=ppc64el label=daily release=xenial
3. $ cat /home/ubuntu/ppc-template.xml
<domain type='kvm'>
<os>
<type>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<devices>
<interface type='network'>
<source network='default'/>
<model type='virtio'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/3'/>
<target port='0'/>
</serial>
<graphics type='vnc' autoport='yes' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
</graphics>
<video/>
</devices>
</domain>
4. $ uvt-kvm create --memory 4096 --template /home/ubuntu/ppc-template.xml
--password=ubuntu --ssh-public-key-file /home/ubuntu/.ssh/authorized_keys
kvmguest-xenial-level1 release=xenial arch=ppc64el label=daily
5. log into this guest (all following steps are in level1 guest to
spawn a level2 guest)
6. ensure kvm_pr is loaded correctly
This is in the extras package which is not installed by default
(other bug). Get it with
$ apt-get install linux-image-extra-virtual
$ modprobe kvm_pr
$ lsmod | grep kvm_pr
7. make sure libvirt default network can start in 2nd level
There likely is a network collision, use virsh net-edit to dix and
then virsh net-start to start the network
8. Get Original Xenial Ubuntu image
wget
http://old-releases.ubuntu.com/releases/16.04.0/ubuntu-16.04-server-ppc64el.iso
9. sudo apt install virtinst
10. $ virt-install --virt-type=kvm --cpu=host --name=nested-xenial
--controller type=scsi,model=virtio-scsi --graphics none --console
pty,target_type=serial --disk
path=/home/ubuntu/test-xenial-virt-inst.qcow2,size=4 --vcpus=4 --ram=2048
--os-type=linux --os-variant ubuntu16.04 --network bridge=virbr0,model=virtio
--cdrom=ubuntu-16.04-server-ppc64el.iso
11. See crash on guest install/boot
* Installing the fixed qemu in the 1st level (not on Bare Metal)
before retrying step 11 should show the issue being fixed
[Regression Potential]
* It is changing features announced to the guest, but then it is only
taking it away in cases it won't work
* The change is ppc64el "only" which restricts the audience to be hit
by regressions and even there kvm_pr (problem state virtualization)
is a rare case usually only for Testing/CI
* Changes are upstream in qemu a while now without being revoked and
come from IBM themselves.
-------
== Comment: #0 - Breno Henrique Leitao <bren...@br.ibm.com> - 2017-02-14
10:03:03 ==
We don't support transactional memory in PR KVM, so don't tell the OS that we
do.
These are the required patches:
commit 2e68f28854f0120c9a938a61b64aaf1eaecb162b
Author: Thomas Huth <th...@redhat.com>
Date: Wed Sep 28 13:16:30 2016 +0200
ppc: Check the availability of transactional memory
KVM-PR currently does not support transactional memory, and the
implementation in TCG is just a fake. We should not announce TM
support in the ibm,pa-features property when running on such a
system, so disable it by default and only enable it if the KVM
implementation supports it (i.e. recent versions of KVM-HV).
These changes are based on some earlier work from Anton Blanchard
(thanks!).
Signed-off-by: Thomas Huth <th...@redhat.com>
Reviewed-by: C?dric Le Goater <c...@kaod.org>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
(cherry picked from commit bac3bf287ab60e264b636f5f00c116a19b655762)
commit 45a4f18e2ec40b96893c780c28ab18c246906355
Author: Thomas Huth <th...@redhat.com>
Date: Wed Sep 28 13:16:29 2016 +0200
hw/ppc/spapr: Fix the selection of the processor features
The current code uses pa_features_206 for POWERPC_MMU_2_06, and
for everything else, it uses pa_features_207. This is bad in some
cases because there is also a "degraded" MMU version of ISA 2.06,
called POWERPC_MMU_2_06a, which should of course use the flags for
2.06 instead. And there is also the possibility that the user runs
the pseries machine with a POWER5+ or even 970 processor. In that
case we certainly do not want to set the flags for 2.07, and rather
simply skip the setting of the pa-features property instead.
Signed-off-by: Thomas Huth <th...@redhat.com>
Reviewed-by: C?dric Le Goater <c...@kaod.org>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
(cherry picked from commit 4cbec30d769a73853b60dc7f275e6e7da9ab5162)
commit 5c179666057a7568306062e2cd030042a25eb57a
Author: Thomas Huth <th...@redhat.com>
Date: Wed Sep 28 13:16:28 2016 +0200
hw/ppc/spapr: Move code related to "ibm,pa-features" to a separate
function
The function spapr_populate_cpu_dt() has become quite big
already, and since we likely have to extend the pa-features
property for every new processor generation, it is nicer
if we put the related code into a separate function.
Signed-off-by: Thomas Huth <th...@redhat.com>
Reviewed-by: C?dric Le Goater <c...@kaod.org>
Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
(cherry picked from commit 230bf719d3a3b144a4ffa441e5d6170ef0ad8999)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664622/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
