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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] powerpc iommu: enable multiple TCE requests
Date: Tue, 20 Aug 2013 11:09:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

Il 20/08/2013 10:49, Alexey Kardashevskiy ha scritto:
> On 08/20/2013 06:39 PM, Paolo Bonzini wrote:
>> Il 20/08/2013 03:36, Alexey Kardashevskiy ha scritto:
>>> 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?
>>
>> Upstream doesn't support migration to older QEMU.
> 
> Hm. That makes things simpler. Then I do not understand why we need
> migration protocol versions as QEMU version in stronger version for
> migration. Ah, offtopic.

Because you have multiple downstreams that can backport arbitrary crap
on top of the same base QEMU version.

In RHEL for example we do some effort to force usage of older version
IDs (or to forcibly leave out subsections) depending on the machine type
you're using.

So even though upstream is limited in the kind of migrations we support,
we provide the infrastructure for downstreams to give stronger guarantees.

>>> This SandyBridge,enforce - what if the destination host running on old
>>> kernel was run without this option - will the migration fail?
>>
>> The destination machine will not even start.
>>
>>>> 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.
>>
>> The question is also whether you consider pSeries support complete
>> enough to be production ready---and until you have versioned machine
>> types I would say you don't.
>>
>> If you still consider it somewhat experimental, I would do as Alex said:
>> make newer QEMU on older KVM as slower, and that's it.
> 
> Sorry if I miss anything, but is not it what the patch already does? :)

No, you need to expose multitce unconditionally in the device tree.

Paolo

> If so, I'll repost this patch + traces rework tomorrow or so.





reply via email to

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