[Top][All Lists]

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

Re: [Qemu-ppc] [PATCH qemu v4 1/3] spapr_iommu: Realloc guest visible TC

From: Alexey Kardashevskiy
Subject: Re: [Qemu-ppc] [PATCH qemu v4 1/3] spapr_iommu: Realloc guest visible TCE table when hot(un)plugging vfio-pci
Date: Wed, 16 Aug 2017 13:30:51 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 09/08/17 17:33, David Gibson wrote:
> On Mon, Jul 24, 2017 at 08:48:45PM +1000, Alexey Kardashevskiy wrote:
>> On 24/07/17 15:53, David Gibson wrote:
>>> On Thu, Jul 20, 2017 at 05:22:29PM +1000, Alexey Kardashevskiy wrote:
>>>> This replaces g_malloc() with spapr_tce_alloc_table() as this is
>>>> the standard way of allocating tables and this allows moving the table
>>>> back to KVM when unplugging a VFIO PCI device and VFIO TCE acceleration
>>>> support is not present in the KVM.
>>> So, I like the idea here, and I think it will work for now, but one
>>> thing concerns me.
>>> AIUI, your future plans include allowing in-kernel accelerated TCE
>>> tables even with VFIO devices.  When that happens, we might have an
>>> in-kernel table both before and after a change in the "need_vfio"
>>> state.
>> The in-kernel table just stays there, mappings will be replayed but in the
>> end of the replay only the hardware table will change.
>>> But you won't be able to have two in-kernel tables allocated at once,
>>> whereas this code relies on having both the old and new tables at once
>>> so it can copy the contents over.
>>> How do you intend to handle that?
>> I intend to make this function no-op when cap_spapr_vfio is present.
>>>> Although spapr_tce_alloc_table() is expected to fail with EBUSY
>>>> if called when previous fd is not closed yet, in practice we will not
>>>> see it because cap_spapr_vfio is false at the moment.
>>> I don't follow this.  How would cap_spapr_vfio be changing at any
>>> point?
>> It depends on the version of the host kernel.
> Ok.  I'm still a bit dubious about the line of reasoning here, but the
> patch is correct for now, so we just have to make sure subsequent
> changes work with it.
> Applied to ppc-for-2.11.

Thanks, what about the other two (2/3, 3/3)?


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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