On 09/28/13 20:51, Mark Salter wrote:
> On Fri, 2013-09-27 at 02:31 +0200, Laszlo Ersek wrote:
>> Hi Mark,
>>
>> just my 2 cents:
>>
>> On 09/26/13 21:33, Mark Salter wrote:
>>> I've been trying out this patch series on AArch64 foundation model.
>>> I have UEFI booting a linux kernel image in an EFI system partition.
>>> But the kernel itself doesn't see the virtio device. If I boot with
>>> an UEFI image without virtio support built in, the same kernel does
>>> see the virtio disk device.
>>>
>>> So, could this be a case of the UEFI virtio driver not releasing the
>>> virtio device?
>>
>> Interesting. We'd only know for sure if we debugged into the kernel
>> ("drivers/virtio/virtio_mmio.c" more precisely).
>
> Well, the virtio_blk probe fails with error of -ENOENT. I tracked that
> down to vm_setup_vq() in virtio_mmio.c:
>
> /* Queue shouldn't already be set up. */
> if (readl(vm_dev->base + VIRTIO_MMIO_QUEUE_PFN)) {
> err = -ENOENT;
> goto error_available;
> }
This is a host (AArch64 foundation model) problem. The current (0.9.5)
virtio spec doesn't spell it out, but from the feedback I got [1] [2], a
full device reset should reset all QueuePFNs too.
(And qemu actually does this on the host side (see [2] again).)
[1]
http://thread.gmane.org/gmane.linux.kernel.virtualization/21022/focus=21027
[2]
https://lists.oasis-open.org/archives/virtio-comment/201310/msg00001.html
On the guest side, the kernel does reset the virtio device up-front:
Checking the current upstream kernel, I believe that virtio-mmio is
initialized first, and virtio-blk comes on top of virtio-mmio.
#1:
virtio_mmio_probe() [drivers/virtio/virtio_mmio.c]
register_virtio_device() [drivers/virtio/virtio.c]
/* We always start by resetting the device, in case a previous
* driver messed it up. This also tests that code path a little. */
dev->config->reset(dev)
vm_reset() [drivers/virtio/virtio_mmio.c] -- via funcptr
writel(0, vm_dev->base + VIRTIO_MMIO_STATUS);
/* device_register() causes the bus infrastructure to look for a
* matching driver. */
err = device_register(&dev->dev);
#2:
virtblk_probe() [drivers/block/virtio_blk.c]
init_vq()
virtio_find_single_vq() [include/linux/virtio_config.h]
vdev->config->find_vqs()
vm_find_vqs() [drivers/virtio/virtio_mmio.c] -- via funcptr
vm_setup_vq()
/* Queue shouldn't already be set up. */
readl(vm_dev->base + VIRTIO_MMIO_QUEUE_PFN)
err = -ENOENT
So, AFAICS, the guest kernel correctly resets the device first, still in
virtio-mmio (the comment is instructive), but then it finds a nonzero
QueuePFN field in virtio-blk.
This looks like an emulator/host problem to me.
Thanks,
Laszlo
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
