From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPL1V-00008N-PW for qemu-devel@nongnu.org; Tue, 20 Jan 2009 13:08:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPL1U-00005F-4u for qemu-devel@nongnu.org; Tue, 20 Jan 2009 13:08:25 -0500 Received: from [199.232.76.173] (port=46054 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPL1U-000057-1H for qemu-devel@nongnu.org; Tue, 20 Jan 2009 13:08:24 -0500 Received: from mail2.shareable.org ([80.68.89.115]:55731) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LPL1T-0008Px-MH for qemu-devel@nongnu.org; Tue, 20 Jan 2009 13:08:23 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1LPL1Q-0007Hd-0z for qemu-devel@nongnu.org; Tue, 20 Jan 2009 18:08:20 +0000 Date: Tue, 20 Jan 2009 18:08:19 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API Message-ID: <20090120180819.GA27464@shareable.org> References: <1232308399-21679-1-git-send-email-avi@redhat.com> <1232308399-21679-2-git-send-email-avi@redhat.com> <18804.34053.211615.181730@mariner.uk.xensource.com> <4974943B.4020507@redhat.com> <18804.44271.868488.32192@mariner.uk.xensource.com> <4974B82F.9020805@redhat.com> <20090119182502.GA2080@shareable.org> <4974C9BA.1050803@redhat.com> <18805.58460.230350.875145@mariner.uk.xensource.com> <49760D1C.3020202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49760D1C.3020202@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Avi Kivity wrote: > Framebuffers? Those are RAM. USB webcams? These can't be interrupted > by SIGINT. Are you saying a guest depends on an O_DIRECT USB transfer > not affecting memory when a USB cable is pulled out. The USB thing is probably more about emulated-UHCI/EHCI pass-through to real host USB devices which aren't emulated in QEMU. > >>We don't have a reliable amount to pass. > >> > >A device which _really_ doesn't have a reliable amount to pass, and > >which is entitled to scribble all over the RAM it was to DMA to even > >if it does only a partial transfer, can simply pass the total transfer > >length. That would be no different to your proposal. > > > > I'm suggesting we do that unconditionally (as my patch does) and only > add that complexity when we know it's needed for certain. Fair enough. Things can be added if needed. But please make it real clear in the DMA API comments that the whole buffer may be overwritten. If a guest actually does depend on this, it won't show up in testing because the whole buffer won't be overwritten except when a bounce copy is used. Linux itself had some issues with _its_ DMA API recently: people have been writing drivers using the Linux DMA API making broken assumptions that happen to work on x86, and work some of the time on other architectures. These things don't show up during driver tests, and are very difficult to track down later. I suspect "overwrites the remaining buffer with randomness/zeros but only under bounce-buffer conditions" will be similarly unlikely to trigger, and very difficult to track down if it causes a problem anywhere. The recent solution in Linux is to add some debugging options which check it's used correctly, even on x86. Here's a final thought, to do with performance: e1000, configured for jumbo frames, receives logs of small packets, and the DMA subsystem has to bounce-copy the data for some reason (Ian suggested maybe always doing that with Xen for DMA to guest RAM?) Without a length passed to unmap, won't it copy 65536 bytes per packet (most from cold cache) because that's the amount set up for DMA to receive from /dev/tap, instead of 256 or 1514 bytes per packet which is their actual size? -- Jamie