On Thu, Nov 29, 2018 at 04:27:31PM +0100, Cédric Le Goater wrote: > [ ... ] > > >>>> +/* > >>>> + * The allocation of VP blocks is a complex operation in OPAL and the > >>>> + * VP identifiers have a relation with the number of HW chips, the > >>>> + * size of the VP blocks, VP grouping, etc. The QEMU sPAPR XIVE > >>>> + * controller model does not have the same constraints and can use a > >>>> + * simple mapping scheme of the CPU vcpu_id > >>>> + * > >>>> + * These identifiers are never returned to the OS. > >>>> + */ > >>>> + > >>>> +#define SPAPR_XIVE_VP_BASE 0x400 > >>> > >>> 0x400 == 1024. Could we ever have the possibility of needing to > >>> consider both physical NVTs and PAPR NVTs at the same time? > >> > >> They would not be in the same CAM line: OS ring vs. PHYS ring. > > > > Hm. They still inhabit the same NVT number space though, don't they? > > No. skiboot reserves the range of VPs for the HW at init. > > https://github.com/open-power/skiboot/blob/master/hw/xive.c#L1093
Uh.. I don't see how they're reserved is relevant.
What I mean is that the ENDs address the NVTs for HW endpoints by the
same (block, index) tuples as the NVTs for virtualized endpoints, yes?
> > I'm thinking about the END->NVT stage of the process here, rather than
> > the NVT->TCTX stage.
> >
> > Oh, also, you're using "VP" here which IIUC == "NVT". Can we
> > standardize on one, please.
>
> VP is used in Linux/KVM Linux/Native and skiboot. Yes. it's a mess.
> Let's have consistent naming in QEMU and use NVT.
Right. And to cover any inevitable missed ones is why I'd like to see
a cheatsheet giving both terms in the header comments somewhere.
[snip]
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
