qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] powerpc iommu: enable multiple TCE requests
Date: Mon, 19 Aug 2013 10:01:38 +0200


Am 19.08.2013 um 09:30 schrieb Alexey Kardashevskiy <address@hidden>:

> On 08/19/2013 01:22 AM, Paolo Bonzini wrote:
>> Il 16/08/2013 11:49, Alexey Kardashevskiy ha scritto:
>>> With KVM, we could fall back to the qemu implementation
>>>> +     * when KVM doesn't support them, but that would be much slower
>>>> +     * than just using the KVM implementations of the single TCE
>>>> +     * hypercalls. */
>>>> +    if (kvmppc_spapr_use_multitce()) {
>>>> +        _FDT((fdt_property(fdt, "ibm,hypertas-functions", hypertas_propm,
>>>> +                           sizeof(hypertas_propm))));
>>>> +    } else {
>>>> +        _FDT((fdt_property(fdt, "ibm,hypertas-functions", hypertas_prop,
>>>> +                           sizeof(hypertas_prop))));
>>>> +    }
>> 
>> This prevents migration from newer kernel to older kernel.  Can you
>> ensure that the fallback to the QEMU implementation works, even though
>> it is not used in practice?
> 
> How would it break? By having a device tree with "multi-tce" in it and not
> having KVM PPC capability for that?
> 
> If this is the case, it will not prevent from migration as the "multi-tce"
> feature is supported anyway by this patch. The only reason for not
> advertising it to the guest is that the host kernel already has
> acceleration for H_PUT_TCE (single page map/unmap) and advertising
> "multi-tce" without having it in the host kernel (but only in QEMU) would
> slow things down (but it still will work).

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.

The usual way to avoid this is to have a command line option to at least make 
it possible for a management tool to nail down feature flags regardless of the 
host configuration.

Considering that IIRC we haven't actually flagged -M pseries as backwards 
compatible (avoid breaking migration, etc) we can probably get away with 
enabling multi-tce always and live with the performance penalty on older host 
kernels.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]