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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html