On Tue, Jul 14, 2015 at 07:48:30PM +0100, Richard W.M. Jones wrote: > > > > /* 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?
After some digging... The insb call is indeed implemented as a "rep ins" in the kernel, and rep appears to be optimized on the host/kvm side, so we might be in luck. The "while (pos-- > 0) inb(FW_CFG_PORT_DATA);" portion is there just in case, since most of the time pos==0 and we don't need to skip any bytes from the given fw_cfg blob before getting to the optimized insb. I guess partial interleaved raw reads of different blobs are *theoretically* possible, but I expect in practice they'll be rather unlikely... Thanks, --Gabriel > 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.