Re: [PATCH RESEND v10 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.07.2022 10:00, Jane Malalane wrote:
> On 30/06/2022 07:03, Jan Beulich wrote:
>> On 30.06.2022 05:25, Tian, Kevin wrote:
>>>> From: Jane Malalane <jane.malalane@xxxxxxxxxx>
>>>> Sent: Wednesday, June 29, 2022 9:56 PM
>>>>
>>>> Introduce a new per-domain creation x86 specific flag to
>>>> select whether hardware assisted virtualization should be used for
>>>> x{2}APIC.
>>>>
>>>> A per-domain option is added to xl in order to select the usage of
>>>> x{2}APIC hardware assisted virtualization, as well as a global
>>>> configuration option.
>>>>
>>>> Having all APIC interaction exit to Xen for emulation is slow and can
>>>> induce much overhead. Hardware can speed up x{2}APIC by decoding the
>>>> APIC access and providing a VM exit with a more specific exit reason
>>>> than a regular EPT fault or by altogether avoiding a VM exit.
>>>
>>> Above is obvious and could be removed.
>>>
>>> I think the key is just the next paragraph for why we
>>> want this per-domain control.
>>
>> Indeed, but the paragraph above sets the context. It might be possible
>> to shorten it, but ...
>>
>>> Apart from that:
>>>
>>> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
>>>
>>>>
>>>> On the other hand, being able to disable x{2}APIC hardware assisted
>>>> virtualization can be useful for testing and debugging purposes.
>>
>> ... I think it is desirable for this sentence to start with "Otoh" or
>> alike.
>>
>> JanHello Jan,
> 
> In the previous email, I was referring to this discussion about the 
> commit message. I haven't sent out a v11 because there was no change 
> other than this one suggested. What I said earlier was that I thought 
> the "Having all APIC interaction exit to Xen for emulation is slow..." 
> paragraph provided context for what I say after but I am happy to remove it.

I'd be fine for it to be kept as you had it, but you really should have
sent out both patches. There are rare cases where sending out individual
updates within a series is reasonable (e.g. to avoid spamming the list
with a large amount of unchanged patches), but I think here you want to
make things easy for committers and not have them hunt down the earlier
version.

Jan