Re: [PATCH v2] Loongarch: KVM: Add KVM hypercalls documentation for LoongArch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux