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

[Michael S. Tsirkin]

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?

-- 
MST