[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
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, (continued)
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Alexey Kardashevskiy, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Paolo Bonzini, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Benjamin Herrenschmidt, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Paolo Bonzini, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Benjamin Herrenschmidt, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Paolo Bonzini, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Benjamin Herrenschmidt, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Paolo Bonzini, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Benjamin Herrenschmidt, 2013/08/20
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Alexander Graf, 2013/08/21
- Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests,
Alexander Graf <=
Re: [Qemu-ppc] [PATCH] powerpc iommu: enable multiple TCE requests, Alexander Graf, 2013/08/16