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: Wed, 21 Aug 2013 08:11:55 +0100

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.


Alex




reply via email to

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