Re: [edk2] [PATCH v2 0/4] OvmfPkg: virtio-blk driver
Thanks Laszlo. Committed in r13801. Two requests for your next virtio series: 1. Add inclusion guards in VirtioBlkDxe/*.h 2. Make OFFSET_OF_VHDR use OFFSET_OF I noticed the -drive file=cd.iso,if=virtio doesn't seem to boot the ISO. This does work for seabios. I wonder if this is luck based on the ISO layout, or if seabios detects this. Perhaps SCSI based virtio will detect it as a CD/DVD, and work correctly? -Jordan On Sun, Sep 30, 2012 at 3:11 PM, Laszlo Ersek ler...@redhat.com wrote: v1-v2: - (no functional changes) - (patches 2 to 4 unchanged) - (rebased to svn rev 13778) - make sure all new files have CRLF line endings - remove author references - move virtio-0.9.5 definitions and structures to Virtio.h - rename IoWrite() / IoRead() to VirtioWrite() / VirtioRead() - make Dev param of CONFIG_READ() / CONFIG_WRITE() explicit - rename CONFIG_READ() / CONFIG_WRITE() to VIRTIO_CFG_READ() / VIRTIO_CFG_WRITE() - open-code goto from VIRTIO_CFG_READ() / VIRTIO_CFG_WRITE(); consequently, simplify call sites where the precise error code doesn't matter - substitute EFI_PAGE_SIZE for SIZE_4KB parameter of ALIGN_VALUE() - replace division by SIZE_4KB with EFI_SIZE_TO_PAGES in RingSize calculation - replace similar division with right shift by EFI_PAGE_SHIFT in calculation of ring base GPFN - retest steps (4) and (5) described below The first patch adds the driver. The rest enables QemuBootOrder to recognize virtio-blk devices. Tested as follows: (1) Booted the Fedora 18 Alpha Live CD (XFCE flavor) with OVMF under RHEL-6.3 qemu-kvm. The ISO image was accessed as an IDE CD-ROM. The target disk was virtio-blk, but in this phase OVMF didn't care about it beyond noticing / enumerating it. (2) Created a 4 GB raw image file with MBR partition table and a single VFAT partition, with a few directories inside. This virtual disk was attached to the virtual machine (while turned off) with virt-manager. At this point 00:05.0 corresponded to the main image, while 00:07.0 corresponded to this made-up MBR image. (3) Edited the VM xml with virsh so that the disks would sit on two functions of the same PCI device (this was not necessary, I just wanted to see if it worked). See the virsh XML fragment below: disk type='file' device='disk' driver name='qemu' type='raw' cache='none'/ source file='/var/lib/libvirt/images/fw-ovmf.g-f18xfcealpha.e-rhel63.img'/ target dev='vda' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x1'/ /disk disk type='file' device='disk' driver name='qemu' type='raw' cache='none'/ source file='/var/lib/libvirt/images/mbr-one-vfat-part.img'/ target dev='vdb' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0' multifunction='on'/ /disk (4) Booted virtual machine and entered the Boot Options text-ui in OVMF. Browsed the directories on mbr-one-vfat-part.img (see (2)), then made sure \EFI\fedora\shim.efi was added as a boot option from the main image. (Full device path: PciRoot(0x0)/Pci(0x5,0x1)/HD(1,GPT,32DBD7E0-D59B-4190-8DE3-A95E75483A13,0x800,0x36800)/\EFI\fedora\shim.efi.) (5) OVMF loaded shim https://github.com/mjg59/shim/, which loaded grub-2 with the Simple File System Protocol. Grub-2 loaded the OS with BlockIo. Grub-1 does not recognize the UEFI device path in (4) as bootable. I plan to write a virtio-scsi driver sometime, which should cooperate with the existent SCSI parts of OVMF, and produce the messaging device path nodes required by grub-1. Many thanks to Paolo Bonzini Jordan Justen. Laszlo Ersek (4): OvmfPkg: introduce virtio-blk driver OvmfPkg: QemuBootOrder: whitespace fix OvmfPkg: QemuBootOrder: lower the required number of OFW nodes to 2 OvmfPkg: QemuBootOrder: recognize virtio-blk OFW device paths OvmfPkg/VirtioBlkDxe/Virtio.h | 176 +++ OvmfPkg/VirtioBlkDxe/VirtioBlk.h | 293 + OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c | 51 +- OvmfPkg/VirtioBlkDxe/VirtioBlk.c | 1431 OvmfPkg/OvmfPkgIa32.dsc|1 + OvmfPkg/OvmfPkgIa32.fdf|1 + OvmfPkg/OvmfPkgIa32X64.dsc |1 + OvmfPkg/OvmfPkgIa32X64.fdf |1 + OvmfPkg/OvmfPkgX64.dsc |1 + OvmfPkg/OvmfPkgX64.fdf |1 + OvmfPkg/VirtioBlkDxe/VirtioBlk.inf | 40 + 11 files changed, 1986 insertions(+), 11 deletions(-) create mode 100644 OvmfPkg/VirtioBlkDxe/Virtio.h create mode 100644 OvmfPkg/VirtioBlkDxe/VirtioBlk.h create mode 100644 OvmfPkg/VirtioBlkDxe/VirtioBlk.c create mode 100644 OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
Re: [edk2] [PATCH v2 0/4] OvmfPkg: virtio-blk driver
On 10/08/12 09:42, Jordan Justen wrote: Thanks Laszlo. Committed in r13801. Two requests for your next virtio series: 1. Add inclusion guards in VirtioBlkDxe/*.h Regarding headers. I have a working virtio-scsi driver now (no nice comments yet), but I have some parts that are shared by virtio-blk and virtio-scsi. You mentioned OvmfPkg/Include/IndustryStandard as a new directory to host the type and macro definitions, but I also have some functions to extract. Where should I put the header file with the function declarations, and the C file with the function definitions? 2. Make OFFSET_OF_VHDR use OFFSET_OF Ugh. For some reason I was convinced that OFFSET_OF didn't exist yet. It's not that I forgot to search for it, I searched and decided it wasn't there. Strange. I noticed the -drive file=cd.iso,if=virtio doesn't seem to boot the ISO. This does work for seabios. I wonder if this is luck based on the ISO layout, or if seabios detects this. I have not tested this scenario. I tried it now (from virt-manager, as usual), but Advanced Options | Disk bus for CD-ROMs only allows two values, IDE and SCSI. Virtio is not listed. Perhaps SCSI based virtio will detect it as a CD/DVD, and work correctly? I tested that now. OVMF boots grub2 from the Fedora-18-Alpha-x86_64-Live-XFCE.iso virtio-scsi CD-ROM. Later the installer fails with https://fedoraproject.org/wiki/Common_F18_bugs#uefi-dvd-fail, but I think that is an initrd problem. Listed from the emergency shell, /proc/modules contains virtio_net and virtio_blk, but not virtio_scsi. I submitted https://bugzilla.redhat.com/show_bug.cgi?id=864012. I tested the same with the Windows 8 Consumer Preview ISO (build 8250). It boots. I powered off the virtual machine at the first window (Windows Setup, language / locale selection). Relevant options on the qemu-kvm command line: -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 ^ -drive file=/filestore/isos/win8/en_windows_8_consumer_preview_debug_checked_build_x64_dvd_811812.iso,if=none,media=cdrom,id=drive-scsi0-0-0-0,readonly=on,format=raw ^ -device scsi-disk,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 ^ ^ Thanks, Laszlo -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/4] OvmfPkg: virtio-blk driver
Il 08/10/2012 09:42, Jordan Justen ha scritto: I noticed the -drive file=cd.iso,if=virtio doesn't seem to boot the ISO. This does work for seabios. I wonder if this is luck based on the ISO layout, or if seabios detects this. I do wonder if it is treating it as a USB (pendrive) image... Paolo -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v2 0/4] OvmfPkg: virtio-blk driver
v1-v2: - (no functional changes) - (patches 2 to 4 unchanged) - (rebased to svn rev 13778) - make sure all new files have CRLF line endings - remove author references - move virtio-0.9.5 definitions and structures to Virtio.h - rename IoWrite() / IoRead() to VirtioWrite() / VirtioRead() - make Dev param of CONFIG_READ() / CONFIG_WRITE() explicit - rename CONFIG_READ() / CONFIG_WRITE() to VIRTIO_CFG_READ() / VIRTIO_CFG_WRITE() - open-code goto from VIRTIO_CFG_READ() / VIRTIO_CFG_WRITE(); consequently, simplify call sites where the precise error code doesn't matter - substitute EFI_PAGE_SIZE for SIZE_4KB parameter of ALIGN_VALUE() - replace division by SIZE_4KB with EFI_SIZE_TO_PAGES in RingSize calculation - replace similar division with right shift by EFI_PAGE_SHIFT in calculation of ring base GPFN - retest steps (4) and (5) described below The first patch adds the driver. The rest enables QemuBootOrder to recognize virtio-blk devices. Tested as follows: (1) Booted the Fedora 18 Alpha Live CD (XFCE flavor) with OVMF under RHEL-6.3 qemu-kvm. The ISO image was accessed as an IDE CD-ROM. The target disk was virtio-blk, but in this phase OVMF didn't care about it beyond noticing / enumerating it. (2) Created a 4 GB raw image file with MBR partition table and a single VFAT partition, with a few directories inside. This virtual disk was attached to the virtual machine (while turned off) with virt-manager. At this point 00:05.0 corresponded to the main image, while 00:07.0 corresponded to this made-up MBR image. (3) Edited the VM xml with virsh so that the disks would sit on two functions of the same PCI device (this was not necessary, I just wanted to see if it worked). See the virsh XML fragment below: disk type='file' device='disk' driver name='qemu' type='raw' cache='none'/ source file='/var/lib/libvirt/images/fw-ovmf.g-f18xfcealpha.e-rhel63.img'/ target dev='vda' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x1'/ /disk disk type='file' device='disk' driver name='qemu' type='raw' cache='none'/ source file='/var/lib/libvirt/images/mbr-one-vfat-part.img'/ target dev='vdb' bus='virtio'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0' multifunction='on'/ /disk (4) Booted virtual machine and entered the Boot Options text-ui in OVMF. Browsed the directories on mbr-one-vfat-part.img (see (2)), then made sure \EFI\fedora\shim.efi was added as a boot option from the main image. (Full device path: PciRoot(0x0)/Pci(0x5,0x1)/HD(1,GPT,32DBD7E0-D59B-4190-8DE3-A95E75483A13,0x800,0x36800)/\EFI\fedora\shim.efi.) (5) OVMF loaded shim https://github.com/mjg59/shim/, which loaded grub-2 with the Simple File System Protocol. Grub-2 loaded the OS with BlockIo. Grub-1 does not recognize the UEFI device path in (4) as bootable. I plan to write a virtio-scsi driver sometime, which should cooperate with the existent SCSI parts of OVMF, and produce the messaging device path nodes required by grub-1. Many thanks to Paolo Bonzini Jordan Justen. Laszlo Ersek (4): OvmfPkg: introduce virtio-blk driver OvmfPkg: QemuBootOrder: whitespace fix OvmfPkg: QemuBootOrder: lower the required number of OFW nodes to 2 OvmfPkg: QemuBootOrder: recognize virtio-blk OFW device paths OvmfPkg/VirtioBlkDxe/Virtio.h | 176 +++ OvmfPkg/VirtioBlkDxe/VirtioBlk.h | 293 + OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c | 51 +- OvmfPkg/VirtioBlkDxe/VirtioBlk.c | 1431 OvmfPkg/OvmfPkgIa32.dsc|1 + OvmfPkg/OvmfPkgIa32.fdf|1 + OvmfPkg/OvmfPkgIa32X64.dsc |1 + OvmfPkg/OvmfPkgIa32X64.fdf |1 + OvmfPkg/OvmfPkgX64.dsc |1 + OvmfPkg/OvmfPkgX64.fdf |1 + OvmfPkg/VirtioBlkDxe/VirtioBlk.inf | 40 + 11 files changed, 1986 insertions(+), 11 deletions(-) create mode 100644 OvmfPkg/VirtioBlkDxe/Virtio.h create mode 100644 OvmfPkg/VirtioBlkDxe/VirtioBlk.h create mode 100644 OvmfPkg/VirtioBlkDxe/VirtioBlk.c create mode 100644 OvmfPkg/VirtioBlkDxe/VirtioBlk.inf -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
