qemu-ppc
[Top][All Lists]
Advanced

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

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


From: Alexander Graf
Subject: Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests
Date: Wed, 21 Aug 2013 08:29:50 +0100

On 21.08.2013, at 08:11, Alexander Graf wrote:

> 
> On 20.08.2013, at 12:38, Benjamin Herrenschmidt wrote:
> 
>> On Tue, 2013-08-20 at 12:14 +0200, Paolo Bonzini wrote:
>>>> I suppose if RH is going to deploy 3.10 and we aren't going to backport
>>>> the multitce patches then there *might* be a case for supporting that
>>>> combo specifically... but it's going to be that bad every time we add
>>>> a new feature with a kernel counter part or start adding the gazillion
>>>> little bits of PAPR that we are still missing ?
>>> 
>>> Yes. :(
>>> 
>>> Unless you consider pSeries KVM not mature enough to provide a guest ABI
>>> (basically supporting live migration only between identical kernels and
>>> QEMUs).  It would make some sense, for example (mutatis mutandis) Red
>>> Hat has a kernel ABI for the "regular" RHEL kernel, but not for the
>>> "real-time" RHEL kernel.
>> 
>> Migration is somewhat less of an issue, and there is to consider what 
>> "products"
>> will actually support KVM on Power. So at this early stage of the game, I 
>> would
>> still play it by ear and stay flexible. When we have something we really 
>> need to
>> have long term support for around the corner (or whatever we haven't 
>> announced
>> yet :-) we'll backport what's needed.
>> 
>> But yes, the minute we have that out, I think the problem will present 
>> itself,
>> at which point we need to probably start considering features in "batches" to
>> limit the explosion of individual options ...
> 
> Yes, I completely agree. I am very happy to postpone that "always stay 
> compatible" mode as far to the future as possible ;). So instead of making 
> multi-tce support runtime switchable (which is a guarantee for exposing 
> things differently to the guest), the easy way out is to always expose it. 
> That way when we pull the trigger later to have a stable interface, we don't 
> have to worry about this piece of code.
> 
> If you like, add an if () on the multi-tce cap and warn the user that his 
> system will be slow and that he should update his kernel. That way you get no 
> headaches on compatibility and people won't get confused why they're being 
> slow because you warned them.

Or keep the code as is, but print a warning to the user on the "kernel does not 
expose multi-tce" case so that he knows he uses an outdated version of KVM. 
That way the guest visible difference is at least visible in the logs.


Alex




reply via email to

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