On Mon, Feb 7, 2011 at 5:12 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: > On 02/07/2011 05:13 AM, Daniel P. Berrange wrote: >> Oh fun, it is actually worse than this. On PPC slot 1 is occupied by the >> VGA adapter, while slot 2 is the IDE controller, so we'll need to make >> some more complex changes here. >> >> We're gonna need to change this for every other arch too, in fact it looks >> like it probably differs for each '-M' arg value too :-( >> >> I'm wondering whether we should just have a separate method for each combo >> rather than trying to make one method do everything. > > Definitely sounds like the sort of thing where we need an arch-specific > callback function that can report the correct reservation information > for that architecture (similar to how we already have arch-specific > callbacks for computing cpu features). Okay, makes sense to me. Would extending "struct qemu_arch_info" in src/qemu/qemu_capabilities.c be suitable enough? We could add a function pointer that reserves some PCI-slots where needed. Currently the table already supports different archs and machines (machines seems NULL everywhere though). Any objections if I have a look into adding this functionality there? (Note, I don't have any no timeframe, it's purely hobby for me.) Thanks, Niels -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list