[PATCH v8 07/10] hyper-v: globalize vp_index

[Vitaly Kuznetsov]

Stephen Hemminger <stephen at networkplumber.org> writes:

> On Wed, 14 Jun 2017 04:31:32 +0000
> Jork Loeser <Jork.Loeser at microsoft.com> wrote:
>
>> > From: Vitaly Kuznetsov [mailto:vkuznets at redhat.com]
>> > Sent: Tuesday, June 13, 2017 19:29
>> > 
>> > Stephen Hemminger <stephen at networkplumber.org> writes:
>> >   
>> > > On Fri,  9 Jun 2017 15:27:33 +0200
>> > > Vitaly Kuznetsov <vkuznets at redhat.com> wrote:
>> > >  
>> > >> To support implementing remote TLB flushing on Hyper-V with a
>> > >> hypercall we need to make vp_index available outside of vmbus module.
>> > >> Rename and globalize.
>> > >>
>> > >> Signed-off-by: Vitaly Kuznetsov <vkuznets at redhat.com>
>> > >> Reviewed-by: Andy Shevchenko <andy.shevchenko at gmail.com>  
>> > >
>> > > This is correct, but needs to be rebased.
>> > > It conflicts with the PCI protocol version 1.2 patches that are in the
>> > > PCI tree.  
>> > 
>> > :-(
>> > 
>> > The question is - what do we do? As far as I understand the intent was to push
>> > this through Greg's char-misc tree. If I rebase it to Bjorn's pci tree patches won't
>> > apply to char-misc and Greg won't take them. I see three possible ways to go:
>> > 1) Take them into char-misc and resolve the conflict in merge window (Linus will
>> > hate us all :-( )
>> > 2) Ask Greg to merge with Bjorn _now_ so we can send the rebased version.
>> > 3) Postpone these patches to the next kernel release. No guarantee we won't
>> > clash with something else :-(
>> > 
>> > So I'm a bit lost. With Hyper-V drivers scattered across multiple trees we're
>> > doomed to have such issues with every relatively big series.  
>> 
>> I would like to see Vitaly's patch-set being integrated shortly (option 1).
>> 
>> In anticipation of this, the PCI protocol version 1.2 patches
>> duplicate the CPU-ID/vCPU-ID mapping. The conflict thus is "just" a
>> re-naming conflict - taking either old or new is fine (one
>> occurrence of conflict). Is this acceptable for conflict management
>> without instilling undue despise?
>> 
>> That said, I am more than happy to help in the resolution. Also, once both changes are merged, I'll remove the duplicated logic.
>> 
>> Regards,
>> Jork
>> 
>
> There a few other options:
> 1) Work with Stephen to resolve merge conflict in linux-next. This means any
>    conflict would get resolved before merge window
> 2) Figure out how to get enabling code in (maybe duplicate functions) and then
>    delete the extra later. For example 1-6 could go in now.
>
> 3) Just wait. The hypercall patches are optimizations and could be deferred
>    the pain with this is carrying more patches and managing the backlog gets
>    to be a real nuisance.

IMO we should go with 1) - the conflict we have is minor. While the code
in this series is an optimization it is an important one and we have
some other work which is currently stuck because this series is not
merged (e.g. Jork's PV spinlocks).

K. Y., do you agree to push it to char-misc now? Can you please send it
to Greg then? Thanks!

-- 
  Vitaly