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).
Normally the driver in the kernel should not fail to detect the presence
of the device (MagicValue / Version / DeviceID / VendorID should always
be readable, only the base address needs to be known).
Once detected, the kernel driver should reset the device (via the status
register), at which point all resources on the host/emulator side should
be released and ready for new configuration.
Can you add ignore_loglevel to your kernel command line, capture the
dmesg after boot in both environments, and compare them?
I wonder about the EFI memmap in particular. And maybe /proc/iomem? The
probe function in the kernel starts with
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem)
return -EINVAL;
if (!devm_request_mem_region(&pdev->dev, mem->start,
resource_size(mem), pdev->name))
return -EBUSY;
... A UEFI driver can register an event for ExitBootServices()
(EVT_SIGNAL_EXIT_BOOT_SERVICES), but AFAIK it's mostly useful for
killing off in-flight "DMA" (in this case, host->guest) transfers.
The VirtioNet driver does that (ie. async requests), but VirtioBlk only
provides BlockIo (not BlockIo2), hence each request completes before
returning control to the caller. ExitBootServices() is available on the
lowest task priority level only, it cannot interrupt other code,
including the loop where VirtioBlkDxe is polling for the host's answer.
An ExitBootServices() event handler must not touch the memory map, so it
couldn't release memory anyway, nor call services that might release
memory indirectly (like closing a protocol, presumably).
In short I can't see how the problem could be caused by not caring about
EVT_SIGNAL_EXIT_BOOT_SERVICES in VirtioBlkDxe. I think our indifference
is justified there.
You might be able to trace virtio_mmio.c with ftrace:
http://lwn.net/Articles/365835/
http://lwn.net/Articles/366796/
http://lwn.net/Articles/370423/
Documentation/trace/ftrace.txt
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=60133471&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
