From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API Date: Wed, 3 Sep 2014 19:03:58 -0700 Message-ID: References: <1409609814.30640.11.camel@pasglop> <1409691213.30640.37.camel@pasglop> <1409695810.30640.57.camel@pasglop> <1409700010.30640.67.camel@pasglop> <1409703942.30640.71.camel@pasglop> <1409704990.30640.76.camel@pasglop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1409704990.30640.76.camel@pasglop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Archive: List-Post: To: Benjamin Herrenschmidt Cc: "linux-s390@vger.kernel.org" , Konrad Rzeszutek Wilk , "Michael S. Tsirkin" , Linux Virtualization , Christian Borntraeger , Paolo Bonzini , "linux390@de.ibm.com" List-ID: On Tue, Sep 2, 2014 at 5:43 PM, Benjamin Herrenschmidt wrote: > On Tue, 2014-09-02 at 17:32 -0700, Andy Lutomirski wrote: >> >> I agree *except* that implementing it will be a real PITA and (I >> think) can't be done without changing code in arch/. My patches plus >> an ifdef powerpc will be functionally equivalent, just uglier. > > So for powerpc, it's a 2 liner inside virtio-pci, but yes, it might be > more of a problem for s390, I'm not too sure what they do in that area. > >> Bigger quirk: on a standard s390 virtio guest configuration, >> dma_map_single etc will fail to link. > > Yuck > >> I tried this in v1 of these >> patches. So we can poke at the archdata all day, but we can't build a >> kernel like that :( > > I would like the s390 people to chime in here, it still looks like the > best way to go if they can fix things on their side :-) > >> So until the dma_ops pointer move into struct device and >> CONFIG_HAS_DMA becomes mandatory (or mandatory enough that virtio can >> depend on it), I don't think we can do it this way. > > I see, it's a bummer because it would be a lot cleaner. > >> I'll send a v5 that is the same as v4 except with physical addressing >> hardcoded in for powerpc. > > Thanks. That will do for now, but ideally we want to make it a function > of some flag from the implementation, so let's see what Rusty has to > say. I've confirmed that ppc64 (on QEMU) breaks without the ppc special case and that ppc64 keeps working with the special case. Once Rusty's patches settle down, I'll rebase onto them and send v5. --Andy