From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH 06/19] KVM: PPC: Book3S HV: add a GET_ESB_FD control to the XIVE native device Date: Mon, 11 Feb 2019 17:42:52 +1100 Message-ID: <9dc53c6bccd6fd303481217f768ec173992431e2.camel@kernel.crashing.org> References: <20190205052822.GE22661@umbus.fritz.box> <4d565738-a99b-0333-8533-037677358faa@kaod.org> <20190206012308.GP22661@umbus.fritz.box> <1745dd9f-2927-cae6-e8da-c350b0bd0a66@kaod.org> <20190207024950.GA22661@umbus.fritz.box> <20190208051523.GD2688@umbus.fritz.box> <9b556f53-fcfb-2ca3-019e-6ced0ec74c2a@kaod.org> <20190208215329.GA9529@blackberry> <8c915ed7-5aa5-1276-6598-d5dcd115dd56@kaod.org> <20190211023842.GE7230@umbus.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, kvm-ppc@vger.kernel.org To: David Gibson , =?ISO-8859-1?Q?C=E9dric?= Le Goater Return-path: In-Reply-To: <20190211023842.GE7230@umbus.fritz.box> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" List-Id: kvm.vger.kernel.org On Mon, 2019-02-11 at 13:38 +1100, David Gibson wrote: > > 1) All in kernel > > The offset always maps directly to guest irq number and the kernel > somehow binds it either to an IPI or a host irq as necessary. > Cédric's original code attempts this, but the mechanism of keeping a > pointer to the VMA can't work. Why do you need a pointer to the VMA anyway ? unmap_mapping_range() doesn't need a VMA for the unmap part, and faults/mmaps have the VMA. > But.. remapping the irqs should be sufficiently infrequent that it > might be ok to consider simply stepping through all the hosting > process's VMAs to do this. Which unmap_mapping_range() does for you as I explained previously. You only need the address space. See how spufs does it (among others). > 2) Remapped in qemu (using memory regions) > > I _think_ (in hindsight) was Cédric's been discussing as the > alternative in more recent posts. > > Qemu maps the IPI pages at one place and the passthrough IRQ pages > somewhere else. The IPIs are mapped into the guest as one memory > region, then any passthrough IRQ pages are mapped over that using > overlapping memory regions. > > I don't think this approach will work well, because it could require a > bunch of separate KVM memory slots, which are fairly scarce. > > 3) Remapped in qemu (using mmap()) > > This is the approach I (and I think Paul) have been suggested in > contrast to (1). > > Qemu maps the IPI pages and maps those into the guest. When we need > to set up a passthrough IRQ, qemu mmap()s its pages directly over the > IPI pages, and it remains mapped into the guest with the same memory > region / memslot as the IPIs are already using. If the passthrough > device is removed we have to remap the IPI pages back into place. > > 4) Dedicated irq numbers > > We never re-use regular guest irq numbers for passthrough irqs, > instead we put them somewhere else and keep those mapped to the > passthrough irq pages. > > I was favouring this approach, but it does mean there will be a guest > visible difference between kernel_irqchip=on and off which isn't > great. > > > (1) is the most elegant _interface_, but as we've seen it's > problematic to implement. Looking at the for_all_vmas() approach > could be interesting, but otherwise option (3) might be the most > practical. > > --