[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file
From: |
Richard W.M. Jones |
Subject: |
Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file |
Date: |
Tue, 14 Jul 2015 19:48:30 +0100 |
User-agent: |
Mutt/1.5.20 (2009-12-10) |
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
Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file, Laszlo Ersek, 2015/07/14
Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file, Matt Fleming, 2015/07/15