Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file

[Gabriel L. Somlo]

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 :)

> > /* 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).

Feel free to kick me if I got all that spectacularly wrong :)

Thanks,
--Gabriel