On Tue, Sep 06, 2016 at 06:48:57PM +0800, Chao Peng wrote: > > > Patches 1-4 are okay, though I think it would be easier to add a -M > > q35-lite too that just removes the legacy devices. The -M q35-lite > > machine doesn't have to support versioning for now. > > Okay, this is also good to have in my mind. > > > > > As you might expect, I don't agree with removing the > > firmware. There's > > room for much more optimization before duplicating firmware code in > > QEMU. I'd rather see numbers for: > > > > 1) qboot optimizations: adopt the fw_cfg DMA interface instead of the > > cbfs flash hack (so that -kernel works), drop PCI bridge > > initialization, > > copy less than 64K of memory from ROM to 0xf0000; > > I can do the evaluation on qboot. Also adding Amnon Ilan, to see if > there is some thing we can do for SeaBios.
AFAIK latest seabios already supports DMA. It's easy to add more config options for seabios if you are so inclined. > > > > 2) Linux optimizations: using an uncompressed image to avoid the cost > > of > > copying and decompressing. QEMU can already load the image at the > > right > > place and the real mode stub can do little more than GDT/IDT setup. > > This works surely. I actually followed your suggestion in v1 to make > kernel multiboot-compatible and then load that kernel in QEMU directly > (Also skipped firmware but some changes in patch 11 would move from > QEMU to guest kernel). This way we also gain benefit of doing mmap > kernel as you talked below. Not sure if this is something you can > accpet. I'm not sure I understand the question here. Accept what? > > > > 3) PAM optimizations: for -M q35-lite initialize the machine with RAM > > from 0xc0000 to 1MB. > > > > I know that you ultimately would like to mmap the kernel, but I would > > like to have a better understanding of where the time is spent. > > > > Thanks, > > > > Paolo
