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)? -- Alexey
signature.asc
Description: OpenPGP digital signature
