On Sat, Jan 26, 2019 at 09:25:04AM +0100, Cédric Le Goater wrote: > Was there a crashing.org shutdown ? > > Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) > by in5.mail.ovh.net (Postfix) with ESMTPS id 43mYnj0nrlz1N7KC > for <clg@xxxxxxxx>; Fri, 25 Jan 2019 22:38:00 +0000 (UTC) > Received: from localhost (localhost.localdomain [127.0.0.1]) > by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x0NLZf4K021092; > Wed, 23 Jan 2019 15:35:43 -0600 > > > On 1/23/19 10:35 PM, Benjamin Herrenschmidt wrote: > > On Wed, 2019-01-23 at 20:07 +0100, Cédric Le Goater wrote: > >> Event Assignment Structure, a.k.a IVE (Interrupt Virtualization Entry) > >> > >> All the names changed somewhere between XIVE v1 and XIVE v2. OPAL and > >> Linux should be adjusted ... > > > > All the names changed between the HW design and the "architecture" > > document. The HW guys use the old names, the architecture the new > > names, and Linux & OPAL mostly use the old ones because frankly the new > > names suck big time. > > Well, It does not make XIVE any clearer ... I did prefer the v1 names > but there was some naming overlap in the concepts. > > >> It would be good to talk a little about the nested support (offline > >> may be) to make sure that we are not missing some major interface that > >> would require a lot of change. If we need to prepare ground, I think > >> the timing is good. > >> > >> The size of the IRQ number space might be a problem. It seems we > >> would need to increase it considerably to support multiple nested > >> guests. That said I haven't look much how nested is designed. > > > > The size of the VP space is a bigger concern. Even today. We really > > need qemu to tell the max #cpu to KVM so we can allocate less of them. > > ah yes. we would also need to reduce the number of available priorities > per CPU to have more EQ descriptors available if I recall well. > > > As for nesting, I suggest for the foreseeable future we stick to XICS > > emulation in nested guests. > > ok. so no kernel_irqchip at all. hmm. That would certainly be step 0, making sure the capability advertises this correctly. I think we do want to make XICs-on-XIVE emulation work in a KVM L1 (so we'd need to have it make XIVE hcalls to the L0 instead of OPAL calls). XIVE-on-XIVE for L1 would be nice too, which would mean implementing the XIVE hcalls from the L2 in terms of XIVE hcalls to the L0. I think it's ok to delay this indefinitely as long as the caps advertise correctly so that qemu will use userspace emulation until its ready. > I was wondering how possible it was to have L2 initialize the underlying > OPAL structures in the L0 hypervisor. May be with a sort of proxy hcall > which would perform the initialization in QEMU L1 on behalf of L2. > -- 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
Attachment:
signature.asc
Description: PGP signature
