10:45 a.m.
On PPC emulated by recent versions of qemu, PCI-bus 0 already has a
macio connected in slot 3 and OHCI on slot 4.
Reference:
- https://bugzilla.redhat.com/show_bug.cgi?id=667345
Signed-off-by: Niels de Vos <ndevos(a)redhat.com>
---
Imho this patch is relatively ugly. Unfortunately I did not find a better
way of changing the reserved PCI-addresses on a per architecture basis. It
can well be that qemuAssignDevicePCISlots() needs to be updated for other
architectures as well. A more modular/dynamic approach might be more
suitable.
Feel free to suggest an alternative way to solve this. Thanks,
Niels
src/qemu/qemu_command.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f78ce71..50e3ad7 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -983,6 +983,14 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
qemuDomainPCIAddressSetPtr addrs)
goto error;
}
+ /* qemu-system-ppc has macio on slot 3 and ohci on slot 4 */
+ if (STREQ(def->os.arch, "ppc")) {
+ if (qemuDomainPCIAddressReserveSlot(addrs, 3) < 0)
+ goto error;
+ if (qemuDomainPCIAddressReserveSlot(addrs, 4) < 0)
+ goto error;
+ }
+
/* Network interfaces */
for (i = 0; i < def->nnets ; i++) {
if (def->nets[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE)
--
1.7.4
6:13 a.m.
On Sat, Feb 05, 2011 at 04:45:15PM +0000, Niels de Vos wrote:
On PPC emulated by recent versions of qemu, PCI-bus 0 already has a
macio connected in slot 3 and OHCI on slot 4.
Reference:
- https://bugzilla.redhat.com/show_bug.cgi?id=667345
Signed-off-by: Niels de Vos <ndevos(a)redhat.com>
---
Imho this patch is relatively ugly. Unfortunately I did not find a better
way of changing the reserved PCI-addresses on a per architecture basis. It
can well be that qemuAssignDevicePCISlots() needs to be updated for other
architectures as well. A more modular/dynamic approach might be more
suitable.
Feel free to suggest an alternative way to solve this. Thanks,
Niels
src/qemu/qemu_command.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f78ce71..50e3ad7 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -983,6 +983,14 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
qemuDomainPCIAddressSetPtr addrs)
goto error;
}
+ /* qemu-system-ppc has macio on slot 3 and ohci on slot 4 */
+ if (STREQ(def->os.arch, "ppc")) {
+ if (qemuDomainPCIAddressReserveSlot(addrs, 3) < 0)
+ goto error;
+ if (qemuDomainPCIAddressReserveSlot(addrs, 4) < 0)
+ goto error;
+ }
+
/* Network interfaces */
for (i = 0; i < def->nnets ; i++) {
if (def->nets[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE)
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.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
11:12 a.m.
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).
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
6:55 a.m.
On Mon, Feb 7, 2011 at 5:12 PM, Eric Blake <eblake(a)redhat.com> 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
9:42 a.m.
On 02/09/2011 05:55 AM, Niels de Vos wrote:
>> 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?
Certainly sounds like the right place.
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.)
Feel free to submit a patch, and to take as long as you need - the
beauty of open source is that everyone scratches their own itches in the
timeframe that they need. When you do post a patch, we'll be sure to
review it based on its merits, and either take it as is or give you
feedback for improving it further.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
5035
days inactive
5039
days old
4 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Niels de Vos