From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYg3G-0000x1-E3 for qemu-devel@nongnu.org; Tue, 22 Oct 2013 13:47:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VYg3A-0007g0-7W for qemu-devel@nongnu.org; Tue, 22 Oct 2013 13:47:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VYg39-0007fo-VA for qemu-devel@nongnu.org; Tue, 22 Oct 2013 13:47:24 -0400 Message-ID: <5266BAA1.5080303@redhat.com> Date: Tue, 22 Oct 2013 19:49:21 +0200 From: Laszlo Ersek MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] QueuePFN peculiarity in virtio-mmio List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Linux Virtualization , Jon Masters , Anthony Liguori , Rusty Russell Cc: "Jordan Justen (Intel address)" , "edk2-devel@lists.sourceforge.net" , "qemu-devel@nongnu.org" , Olivier Martin , Mark Salter Hi, "Appendix X: virtio-mmio" in the virtio spec says =95 0x040 | RW | QueuePFN [...] When the Guest stops using the queue it must write zero (0x0) to this register. [...] and Virtqueue Configuration [...] 2. Check if the queue is not already in use: read QueuePFN register, returned value should be zero (0x0). [...] I think this in itself is already suboptimal, because a guest that crashes and reboots (while the emulator itself survives) will not be able to use the device after said reboot (it has never re-set QueuePFN to zero). But, more importantly: I think that resetting the device (by writing 0 to its status register) should include (ie. *guarantee*) the effects of setting QueuePFN to zero for all imaginable queues of the device. This way, a defensive guest that starts up by resetting the device (*) after identifying it via MagicValue / Version / DeviceID / VendorID would be able to use the device regardless of the device's prior QueuePFN setting(s). (*) Resetting the device is the first step in "2.2.1 Device Initialization Sequence". It "is not required on initial start up", but as a guest driver can never be sure whether the startup in question is the initial one, a defensive driver will always start with device reet. The question arises because Olivier has posted a series to edk2-devel that adds virtio-mmio support to TianoCore, and Mark tested it (using OVMF) with a Linux guest and found problems. Namely, OVMF itself can drive the virtio devices via virtio-mmio, but the Linux kernel booted from OVMF can not. The reason is the missing zeroing of QueuePFN when OVMF is exiting. (I'm just paraphrasing the analysis.) I think - that resetting the device (via its status register) should make the host forget *all* prior configuration, including QueuePFN, - and that the Linux driver should reset the device as first step. So: - What's the motivation for the "acquire/release" semantics of QueuePFN? - Am I right that device reset should force a QueuePFN release too? Thanks, Laszlo