Subject: Re: [PATCH v2 2/4] KVM: x86: replace kvm_apic_id with
 kvm_{x,x2}apic_id
To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= <rkrcmar@redhat.com>
References: <20161213163001.4567-1-rkrcmar@redhat.com>
 <20161213163001.4567-3-rkrcmar@redhat.com>
 <304d7935-6a0a-2296-b611-02177c888bb5@redhat.com>
 <20161214171232.GA5594@potion>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        Paolo Bonzini <pbonzini@redhat.com>,
        Igor Mammedov <imammedo@redhat.com>
From: David Hildenbrand <david@redhat.com>
Organization: Red Hat GmbH
Message-ID: <fdacbbab-9c6f-0ac1-f706-23365f2ab6c6@redhat.com>
Date: Wed, 14 Dec 2016 18:26:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20161214171232.GA5594@potion>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1787
Lines: 57


>> think I'd even prefer here a simple
>>
>> aid = kvm_xapic_id(apic);
>> if (apic_x2apic_mode(apic))
>> 	aid = kvm_x2apic_id(apic);
>>
>> that would keep changes minimal and I don't really see any benefit in the
>> code when splitting handling up.
>
> It is neccesassary to write an entry for both IDs and I wanted to split
> it before [4/4], because doing both changes at once seemed hard to
> grasp.
>
> Putting it here didn't work well either ... is a separate patch for the
> hunk below better, or would you prefer to have it in [4/4]?

I actually would prefer to have it in 4/4, but not sure if it is worth 
yet another round. Anyhow,

Reviewed-by: David Hildenbrand <david@redhat.com>

for this patch (with the 256 fixed)

>
>> Patch 4 then simply can fixup setting code
>>
>> if (aid <= new->max_apic_id && !new->phys_map[aid])
>> 	new->phys_map[aid] = apic;
>>
>> (if I am not missing some important corner case here)
>
> The trick is that we want to do the following even in xAPIC mode:
>
>   new->phys_map[kvm_x2apic_id(apic)] = apic;
>
> This is the main idea of the hotplug hack -- to allow unique addressing
> of processors that were reset in xAPIC mode.  (And I add a disgusting
> "x2apic_id > 0xff" condition in [4/4], because we still allow guests to
> change xAPIC IDs, which wouldn't play nice with this.)
>
> Hardware does a superset of this, because it only looks at lower 8 bits
> of the desination ID when delivering to xAPIC.
>
> When kvm_x2apic_id(apic) != kvm_xapic_id(apic), then the APIC is in
> xAPIC mode so we definitely want to keep xAPIC working, hence
>
>   if (!apic_x2apic_mode(apic))
>   	new->phys_map[kvm_xapic_id(apic)] = apic;

Okay, so this is is the case I missed in patch 4 :)

Thanks for the explanation and sorry for the noise.

-- 

David