On 08/09/17 19:35, Brijesh Singh wrote:
> On 08/09/2017 09:39 AM, Laszlo Ersek wrote:
>> On 08/07/17 13:58, Brijesh Singh wrote:
>>> Currently, virtio drivers provides the system physical address to the
>>> However, some systems may feature an IOMMU that requires the drivers
>>> to pass
>>> the device addresses to the device - which are then translated by the
>>> into physical addresses in memory. The patch series introduces new
>>> functions in VIRTIO_DEVICE_PROTOCOL which can be used for mapping a
>>> physical address to device address.
>>> The approach that this patch series takes is to maps the system physical
>>> address to device address for buffers (including rings, device specifc
>>> request and response pointed by vring descriptor, and any further
>>> reference by those request and response).
>>> Patch 1 - 3:
>>> Defines and implements new member functions to map a system
>>> physical address
>>> to device address. The patch implements Laszlo's suggestion .
>> (1) I guess under  you meant the following message:
> Yes, thank you :) I did not realized that I forgot adding the link.
>> If you want, you can add that link to the commit message of patch #1.
>> (2) But, that's not my main point here. Before I forget, I'd like to
>> point out that you missed one of the three virtio protocol
>> implementations -- see my point (5.4) in the above-referenced message
>> --, namely:
>>> - "ArmVirtPkg/VirtioFdtDxe" (via
>>> "OvmfPkg/Library/VirtioMmioDeviceLib") binds virtio-mmio devices,
>>> and offers virtio 0.9.5 semantics.
>> So please replicate patch v1 03/14 to
>> "OvmfPkg/Library/VirtioMmioDeviceLib". Otherwise, the modified virtio
>> device drivers will crash when they are built for ArmVirtPkg and used
>> over virtio-mmio transports.
> Sure, I will make the necessary changes in VirtioMmioDeviceLib and try
> do the build test but I don't have aarch64 platform to verify at the
Actually, dependent on your GNU/Linux distribution, it is pretty easy to
do on x86_64 too. It comes together from two parts:
(1) installing an aarch64 cross compiler
(2) installing qemu-system-aarch64 (from source or distro package),
and then either using it directly (from the cmdline) or with the
The only "real" difference is that it's going to use TCG and not KVM
(software emulation rather than hardware virtualization), so it will be
slower, but that's not really a problem if you only care about your VM
until the firmware boots the OS :)
On Fedora, the cross-compiler (and cross-binutils) packages are built
from the following SRPMs:
Linaro distributes distro-independent cross compilers:
Build instructions for ArmVirtQemu, and usage hints for the QEMU command
line, can be found in the Linaro Wiki:
>> (3) Starting with your v2, please add a reminder to your blurb -- for
>> Ard and myself -- that before merging this, we should regression-test it
>> on aarch64.
> Will do
edk2-devel mailing list