From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LOyoB-0004ZU-5c for qemu-devel@nongnu.org; Mon, 19 Jan 2009 13:25:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LOyo7-0004ZI-J9 for qemu-devel@nongnu.org; Mon, 19 Jan 2009 13:25:10 -0500 Received: from [199.232.76.173] (port=34535 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LOyo7-0004ZF-Br for qemu-devel@nongnu.org; Mon, 19 Jan 2009 13:25:07 -0500 Received: from mail2.shareable.org ([80.68.89.115]:38359) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LOyo6-0000OS-TF for qemu-devel@nongnu.org; Mon, 19 Jan 2009 13:25:07 -0500 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1LOyo2-0000dE-Ph for qemu-devel@nongnu.org; Mon, 19 Jan 2009 18:25:02 +0000 Date: Mon, 19 Jan 2009 18:25:02 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 1/5] Add target memory mapping API Message-ID: <20090119182502.GA2080@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4974B82F.9020805@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: > In fact, we could even say that the virtual hardware doesn't support > dma-to-mmio at all and MCE the guest. I'm sure no x86 guest would even > notice. Don't know about non-x86. Guest userspace does: 1. mmap() framebuffer device. 2. read() from file opened with O_DIRECT. Both are allowed by non-root processes on Linux. (I imagine this might be more common in some obscure DOS programs though). Think also variation with reading from a video capture device into video memory. I've seen that done on x86, never seen it (yet) on non-x86 :-) However, that is known to break on some PCI bridges. I'm not sure if it's reasonable to abort emulation with an MCE in this case. > >I think my question about partial DMA writes is very relevant. If we > >don't care about that, nor about the corresponding notification for > >reads, then the API can be a lot simpler. > > I don't see a concrete reason to care about it. Writing zeros or junk after a partial DMA is quite different to real hardware behaviour. Virtually all devices with a "DMA count" register are certain to have not written to a later address when DMA stops. QEMU tries to do a fairly good job at emulating devices with many of their quirks. It would be odd if the high-performance API got in the way of high-quality device emulation, when that's wanted. Potential example: If a graphics card or video capture card, or USB webcam etc. (more likely!) is doing a large streaming DMA into a guests's userspace process when that process calls read() (in the guest OS), and the DMA is stopped for any reason, such as triggered by a guest OS SIGINT or simply the data having ended, the guest's userspace can reasonably assume data after the count returned by read() is untouched. Just as importantly, the guest OS in that example can assume that the later pages are not dirtied, therefore not swap them, or return them to its pre-zero pool or whatever. This is a legitimate guest OS optimisation for streaming-DMA-with-unknown-length devices. This can happen without a userspace process too. I'm guessing truncated DMAs using this API are always going to dirty only an initial part of the buffer, not arbitrary regions. (In rare cases where this isn't true, don't use the API). So wouldn't it be trivial to pass "amount written" to the unmap function - to be used in the bounce buffer case? -- Jamie