On 03/10/2017 10:38 AM, Thomas Huth wrote: > On 10.03.2017 09:53, Cédric Le Goater wrote: >> On 03/10/2017 09:48 AM, Cédric Le Goater wrote: >>> On 03/09/2017 06:27 PM, Thomas Huth wrote: >>>> This test has two purposes: First, check whether the hypervisor can be >>>> destabilized by writing random values into the SPRs of the PowerPC CPU >>>> (this indeed revealed a bug last year, see CVE-2016-3044). >>>> Second, this test can be used to check whether the SPRs are synchronized >>>> properly between the KVM host CPU and QEMU, e.g. when migrating the VM >>>> from one QEMU instance to another. >>>> The test first fills the various SPRs with some non-zero value, then reads >>>> the values back into a first array. It then either sleeps a short period >>>> of time (for testing without migration, in the hope that we're rescheduled >>>> on another host CPU), or it waits for a key or NMI (with the '-w' option) >>>> so that it is possible to migrate the VM before continuing. The test then >>>> finally reads the values from the SPRs back into another array and then >>>> compares them with the initial values. >>>> Currently the test only supports the SPRs from the PowerISA v2.01 >>>> (PowerPC 970) and PowerISA v2.07 specification (i.e. POWER8 CPUs), >>>> but other versions should be pretty easy to add later. >>>> >>>> Signed-off-by: Thomas Huth <thuth@xxxxxxxxxx> >>> >>> It looks good to me. I gave it a try and it worked fine with some >>> extra tuning in the migration script. >>> >>> LDFLAGS needs fix for binutils 2.28 but that is another issue. >> >> An here's the "fix" for it. I haven't studied deeply the question >> though. > > I think this could be an explanation for this issue: > https://lists.gnu.org/archive/html/bug-gnu-utils/2002-08/msg00242.html > > Could you please check whether it works with "-n" instead of "-N", too? > If so, I think that would be the better option. It works. I will send the patch Thanks, C. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
