On 01/28/10 05:39, Kevin O'Connor wrote:
I think defining accessor functions for every piece of data passed through qemu-cfg interface is going to get tiring. I'd prefer to extend the existing qemu-cfg "file" interface for new content. For example, add a helper with something like: int qemu_cfg_get_file(const char *name, void *dest, int maxsize);
Hi Kevin, I think switching qemu_cfg to use a file name based interface would be a nice feature, but I think it should be independent of this patch. I am CC'ing Gleb on this as he did the original design I believe.
- if (kvm_para_available()) - // 4 pages before the bios, 3 pages for vmx tss pages, the - // other page for EPT real mode pagetable - add_e820(0xfffbc000, 4*4096, E820_RESERVED); + if (kvm_para_available()) { + u32 count; + + count = qemu_cfg_e820_entries(); + if (count) { + struct e820_entry entry; + int i; + + for (i = 0; i< count; i++) { + qemu_cfg_e820_load_next(&entry); + add_e820(entry.address, entry.length, entry.type); + }and then this becomes: struct e820entry map[128]; int len = qemu_cfg_get_file("e820map",&map, sizeof(map)); if (len>= 0) for (i=0; i<len / sizeof(map[0]); i++) add_e820(map[i].start, map[i].size, map[i].type); The advantage being that it should be possible to write one set of helper functions in both qemu and seabios that can then be used to pass arbitrary content.
The only issue here is that I designed the Seabios portion to not rely on the size of the struct, to avoid having to statically reserve it like in your example. Having the qemu_cfg_get_file() function return a pointer to a file descriptor and then have a qemu_cfg_read() helper that takes the descriptor as it's first argument would avoid this problem.
As a side note, it should probably do the e820 map check even for qemu users (ie, not just kvm).
Ah I didn't realize Seabios would try to use the fw_cfg interface if it wasn't running on top of QEMU. That would be good to do. Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
