Re: [Qemu-devel] [PATCH] powerpc iommu: enable multiple TCE requests

[Alexey Kardashevskiy]

On 08/19/2013 07:47 PM, Paolo Bonzini wrote:
> Il 19/08/2013 10:44, Alexey Kardashevskiy ha scritto:
>>>> It means that if you use the same QEMU version with the same command
>>>> line on a different kernel version, your guest looks different because
>>>> we generate the dtb differently.
>> Oh. Sorry for my ignorance again, I am not playing dump or anything like
>> that - I do not understand how the device tree (which we cook in QEMU) on
>> the destination can possibly survive migration and not to be overwritten by
>> the one from the source. What was in the destination RAM before migration
>> does not matter at all (including dt), QEMU device tree is what matters but
>> this does not change. As it is "the same QEMU version", hypercalls are
>> supported anyway, the only difference where they will be handled - in the
>> host kernel or QEMU. What do I miss?
> 
> Nothing, I just asked to test that handling the hypercall in QEMU works.

Well, I was asking rather Alex :)

> On x86 we have a similar problem, though with cpuid bits instead of the
> device tree.  An older kernel might not support some cpuid bits, thus
> "-cpu SandyBridge" might have different cpuid bits depending on the host
> processor and kernel version.  This is handled by having an "enforce"
> mode where "-cpu SandyBridge,enforce" will fail to start if the host
> processor or the kernel is not new enough.

Hm. Here we might have a problem like this is we decide to migrate from
QEMU with this patch running on modern kernel to QEMU without this patch
running on old kernel - for this we might want to be able to disable
"multi-tce" via machine options on newer kernels. Do we care enough to add
such a parameter or we just disable migration and that's it?

This SandyBridge,enforce - what if the destination host running on old
kernel was run without this option - will the migration fail? What is the
mechanism? Do machine options migrate? I looked at target-i386/cpu.c but
did not see the quick answer.


> But in this case, you do not need this because the hypercall works if
> emulated by QEMU.  I like Alex's solution of making it universally
> available in the dtb.

The solution would be good if we did not already have H_PUT_TCE accelerated
for emulated devices in the host kernel but we do have it.


-- 
Alexey