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

Re: [PATCH v3 07/39] xen/riscv: introduce CPU_NONE



> Introduce CPU_NONE, a CPU number which doesn't identify any physical
> CPU, to be used wherever a pCPU has to be recorded but there may be
> none.
> 
> Its first user is vsfile_cpu in struct vimsic_state, which records the
> pCPU whose h/w guest interrupt file backs the vCPU's IMSIC VS-file.
> NR_CPUS has been used there as the value meaning that there is no such
> pCPU, i.e. that the s/w VS-file is in use. NR_CPUS is however an upper
Nit: It's hard to understand when reading the message why s/w is mentioning.
I'd reword it to:
    ```
    NR_CPUS has been used there to mean that no h/w guest interrupt file is
    attached (i.e. the vCPU uses the s/w VS-file), so there is no pCPU to
    record.
    ```
> bound rather than a "no CPU" marker, and it already carries other
> meanings: hartid_to_cpuid() returns it for a hart Xen doesn't know, and
> pcpu_info[] uses it for an entry whose processor_id isn't valid yet.
> Use CPU_NONE for vsfile_cpu instead, so that the s/w VS-file case can't
> be mistaken for any of those.
Nit: Same as above, I'd prefer something like:
    ```
    Use CPU_NONE for vsfile_cpu instead, so that "no h/w guest interrupt
    file attached" can't be mistaken for an unknown hart or a not-yet-valid
    pcpu_info[] entry.
    ```

Reviewed-by: Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>

-- 
Baptiste Le Duc <baptiste.le-duc@xxxxxxxxxx>



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.