Re: [PATCH] x86/hvm: Widen condition for is_hvm_pv_evtchn_vcpu()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.05.2022 12:38, Jane Malalane wrote:
> On 18/05/2022 10:09, Jan Beulich wrote:
>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
>> unless you have verified the sender and know the content is safe.
>>
>> On 13.05.2022 17:39, Roger Pau Monné wrote:
>>> On Wed, May 11, 2022 at 04:14:23PM +0100, Jane Malalane wrote:
>>>> Have is_hvm_pv_evtchn_vcpu() return true for vector callbacks for
>>>> evtchn delivery set up on a per-vCPU basis via
>>>> HVMOP_set_evtchn_upcall_vector.
>>>>
>>>> is_hvm_pv_evtchn_vcpu() returning true is a condition for setting up
>>>> physical IRQ to event channel mappings.
>>>
>>> I would add something like:
>>>
>>> The naming of the CPUID bit is a bit generic about upcall support
>>> being available.  That's done so that the define name doesn't get
>>> overly long like XEN_HVM_CPUID_UPCALL_VECTOR_SUPPORTS_PIRQ or some
>>> such.
>>
>> On top of this at least half a sentence wants saying on why a new
>> CPUID bit is introduced in the first place. This doesn't derive in
>> any way from title or description. It would be only then when it
>> is additionally explained why the name was chosen like this.Indeed it is 
>> incomplete, thanks for pointing that out.
> 
> I could add:
> "A CPUID bit is added so that guests know whether the check
> in is_hvm_pv_evtchn_domain() will fail when using
> HVMOP_set_evtchn_upcall_vector. This matters for guests that route
> PIRQs over event channels since is_hvm_pv_evtchn_domain() is a
> condition in physdev_map_pirq()."
> 
> Would this be enough clarification?

Yes, thanks.

Jan