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
