On Tue, Jul 14, 2015 at 02:23:14PM -0400, Gabriel L. Somlo wrote: > On Tue, Jul 14, 2015 at 10:43:46AM +0100, Richard W.M. Jones wrote: > > On Mon, Jul 13, 2015 at 04:09:37PM -0400, Gabriel L. Somlo wrote: > > > 3. I'm currently only handling x86 and I/O ports. I could drop the > > > fw_cfg_dmi_whitelist and just check the signature, using mmio where > > > appropriate, but I don't have a handy-dandy set of VMs for those > > > architectures on which I could test. Wondering if that's something > > > we should have before I officially try to submit this to the kernel, > > > or whether it could wait for a second iteration. > > > > $ virt-builder --arch armv7l fedora-22 > > or: > > $ virt-builder --arch aarch64 fedora-22 > > then: > > $ virt-builder --get-kernel fedora-22.img > > > > and then boot is using the right qemu command, probably something > > like: > > > > $ qemu-system-arm \ > > -M virt,accel=tcg \ > > -cpu cortex-a15 \ > > -kernel vmlinuz-4.0.4-301.fc22.armv7hl+lpae \ > > -initrd initramfs-4.0.4-301.fc22.armv7hl+lpae.img \ > > -append "console=ttyAMA0 root=/dev/vda3 ro" \ > > -drive file=fedora-22.img,if=none,id=hd \ > > -device virtio-blk-device,drive=hd \ > > -serial stdio > > > > The root password is printed in virt-builder output. > > Thanks, that should help (once I figure out how to *really* start it, > right now it hangs at "reached target basic system", and spews garbage > if I hit 'escape', probably in an attempt to paint the text-mode > progress bar... Then it throws me into a dracut prompt, complaining > that it can't find /dev/vda3... > > But I'm sure I'll sort it out eventually :)
That error, as I guess you know, indicates that the disk image is not being presented as virtio-blk to the guest. I know for sure (because I tested the command line above earlier) that the armv7l guest can see virtio-blk. I didn't test the aarch64 guest. > > > /* read chunk of given fw_cfg blob (caller responsible for sanity-check) > > > */ > > > static inline void fw_cfg_read_blob(uint16_t select, > > > void *buf, loff_t pos, size_t count) > > > { > > > mutex_lock(&fw_cfg_dev_lock); > > > outw(select, FW_CFG_PORT_CTL); > > > while (pos-- > 0) > > > inb(FW_CFG_PORT_DATA); > > > insb(FW_CFG_PORT_DATA, buf, count); > > > mutex_unlock(&fw_cfg_dev_lock); > > > } > > > > How slow is this? > > Well, I think each outw() and inb() will result in a vmexit, with > userspace handling emulation, so much slower comparatively than > inserting into a list (hence mutex here, vs. spinlock there). I wonder if using a string instruction (ie. rep insb etc) would be faster. On x86, qemu specifically optimizes these. Maybe GCC turns the above into a string instruction? The reason I note all this is because there has been an ongoing discussion about the slowness of fw_cfg. Starting in 2010 in fact: https://lists.gnu.org/archive/html/qemu-devel/2010-07/msg00962.html https://lists.gnu.org/archive/html/qemu-devel/2011-10/msg00996.html On aarch64 kernel loading is really slow because it can only transfer (IIRC) 8 bytes at a time, and there are no string instructions we can use to speed it up. A long time ago I wrote a memcpy and a "pseudo-DMA" interface for fw_cfg, but they were both roundly rejected as you can find in the archives. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org