qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Configuration vs. compat hints


From: Markus Armbruster
Subject: [Qemu-devel] Re: Configuration vs. compat hints
Date: Mon, 15 Jun 2009 13:35:02 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

Avi Kivity <address@hidden> writes:

> On 06/15/2009 12:08 PM, Mark McLoughlin wrote:
>>> This last option makes sense to me: in a real world the user has
>>> control over where he places the device on the bus, so why
>>> not with qemu?
>>>      
>>
>> Yep, most people seem to agree that it makes sense to allow this, but
>> some believe it should only be via a machine description file, not the
>> command line.
>>    
>
> I don't understand this opposition.  It's clear a machine config file
> is a long way in our future.  It's also clear lack of stable PCI
> addresses hurts us now.

Correct.

>> However, the first problem is that it isn't a solution to the guest ABI
>> problem more generally.
>>    
>
> pci_addr was never meant to bring world peace, just stable PCI
> addresses.  The other issues should be addressed separately.
>
>> And the second problem is that for e.g. libvirt to use it, it would have
>> to be possible to query qemu for what PCI slots were assigned to the
>> devices - libvirt would need to be able to parse 'info pci' and match
>> the devices listed with the devices specified on the command line.
>>    
>
> If all devices (including vga, ide) are set up with pci_addr, then
> this is unneeded.  You do need to export available slot numbers from
> qemu.

Not really.  QEMU gives just the host bridge a fixed slot[*].  All the
other slots are available.

The real problem is devices that get implicitly added, like the SCSI
controller.  Those devices get their slots auto-assigned, which can
interfere with slot numbers chosen by the user.  We need a way to avoid
that, as you suggested elsewhere in this thread.


[*] There's an exception or two for oddball targets.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]