On 2024/8/28 09:07, maobibo wrote: > Zenghui, > > On 2024/8/27 上午1:00, Zenghui Yu wrote: > > > > On 2024/8/26 13:47, Dandan Zhang wrote: > > > +KVM Hypercalls Documentation > > > +============================ > > > + > > > +The template for each hypercall is as follows: > > > + > > > +1. Hypercall name > > > +2. Purpose > > > + > > > +1. KVM_HCALL_FUNC_PV_IPI > > > > Is it still a work-in-progress thing? I don't see it in mainline. > It should be KVM_HCALL_FUNC_IPI here. Good! So that I can probably read further. :-) > > > +------------------------ > > > + > > > +:Purpose: Send IPIs to multiple vCPUs. > > > + > > > +- a0: KVM_HCALL_FUNC_PV_IPI > > > +- a1: Lower part of the bitmap for destination physical CPUIDs > > > +- a2: Higher part of the bitmap for destination physical CPUIDs > > > +- a3: The lowest physical CPUID in the bitmap > > > > - Is it a feature that implements IPI broadcast with a PV method? > > - Don't you need to *at least* specify which IPI to send by issuing this > > hypercall? > Good question. It should be documented here. PV IPI on LoongArch > includes both PV IPI multicast sending and PV IPI receiving, and SWI is Oh yup, I intended to say "multicast". Thanks for the explanation. > used for PV IPI inject since there is no VM-exits accessing SWI registers. > > > > > But again, as I said I know nothing about loongarch. I might have > > missed some obvious points. > > > > > + > > > +The hypercall lets a guest send multiple IPIs (Inter-Process > > > Interrupts) with > > > +at most 128 destinations per hypercall.The destinations are > > > represented in a > > ^ > > Add a blank space. > > > > > +bitmap contained in the first two input registers (a1 and a2). > > > + > > > +Bit 0 of a1 corresponds to the physical CPUID in the third input > > > register (a3) > > > +and bit 1 corresponds to the physical CPUID in a3+1 (a4), and so on. > > > > This looks really confusing. "Bit 63 of a1 corresponds to the physical > > CPUID in a3+63 (a66)"? > The description is problematic, thanks for pointing it out. > It should be value of register a3 plus 1, rather than a4, how about > *"the physical CPUID in a3 + 1"* here? Better than the original version, I think. Thanks, Zenghui
