Re: [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges

[Alexander Graf]

On 23.11.2012, at 15:18, Michael S. Tsirkin wrote:

> On Fri, Nov 23, 2012 at 03:03:24PM +0100, Alexander Graf wrote:
>> 
>> On 23.11.2012, at 15:01, Michael S. Tsirkin wrote:
>> 
>>> On Fri, Nov 23, 2012 at 02:44:15PM +0100, Alexander Graf wrote:
>>>> 
>>>> On 23.11.2012, at 14:44, Michael S. Tsirkin wrote:
>>>> 
>>>>> On Fri, Nov 23, 2012 at 11:59:51PM +1100, David Gibson wrote:
>>>>>>> Look, even if solution using a required property is less elegant for CLI
>>>>>>> use, it will work, won't it?
>>>>>>> So how about we merge it so that things work, and then we can discuss a
>>>>>>> patch on top that auto-generates this property?
>>>>>> 
>>>>>> Well, there you have a point.  And actually I've realised there are
>>>>>> other things we need to assign uniquely for each PHB and don't yet (IO
>>>>>> window addresses).  So I need to look at a wider rework of this, which
>>>>>> I'll start on next week.
>>>>> 
>>>>> Fine. Basically my point is it's typically a mistake to
>>>>> make some userspace visible parameter depend on order
>>>>> of initialization of devices in qemu. I don't insist
>>>>> on making users fully specify such parameters but it
>>>>> is one way to do this.
>>>> 
>>>> I think it's reasonable to require to be able to specify it. If you
>>>> don't, it's fine to base on device order IMHO.
>>> 
>>> Let me clarify why it's not fine.  My understanding is these addresses
>>> do not change across reboots on real hardware.  On the other hand order
>>> of initialization can change because of internal changes in qemu;
>>> thus shut down and start guest under another qemu version
>>> changes addresses.
>>> 
>>> So it's a bug. No?
>>> 
>>>> But you have to have the ability to specify it by hand if your
>>>> management tool of choice actually wants reproducible results.
>>>> 
>>>> 
>>>> Alex
>>> 
>>> How do you know whether your guest relies on reproducible results?
>>> You typically don't. Imagine a guest which does rely on this. Then:
>>> 
>>> What I propose: user runs qemu with many PHBs but with no iobns, gets error
>>> 'initialization failed. please add iobn=XXXX where XXXX is a unique
>>> number 1 to 64K.'
>>> 
>>> What you propose: user runs qemu with many PHBs but with no iobns,
>>> guest fails to boot or behaves incorrectly.
>>> 
>>> I think as a user I prefer the first type of failure. No?
>> 
>> I tend to disagree. The device creation logic should stay identical
>> with the same versioned machine. So if I use -M pc-0.12, I am
>> guaranteed that QEMU's internal semantics on which device goes where
>> does not change.
> 
> This is exactly why you should not rely on device initialization
> order for your address allocator - it is not guaranteed to
> be consistent.
> 
>> For unstable machine types (which -M pseries is, same as -M pc), we
>> don't guarantee that the guest view stays stable across version
>> updates FWIW. So if we want to give the user a stable view of the
>> world, we would need to create a -M pseries-1.3 which then would
>> always keep the same device creation order.
>> 
>> It's the same for x86, no?
>> 
>> 
>> Alex
> 
> Same for x86 in that we broke guests in the past by changing order,
> and the lesson is to always require full specification if possible.
> Only reason we keep pci slot allocation around is for
> backward compatibility.

Yeah, that's why I would expect libvirt for example to always pass in pci slot 
ids manually for example. But if you want a convenience QEMU command line, that 
is not guaranteed to be identical across different versions.

So IMHO it's fine to have a fuzzy non-consistent fallback as long as it's 
possible to specify the consistent variant. I guess that's a matter of taste 
really :).


Alex