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

[Jane Malalane <Jane.Malalane@xxxxxxxxxx>]

On 11/07/2022 09:26, Jan Beulich wrote:
> 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.

Apologies, makes sense.

Thanks,

Jane.