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

["Michael S. Tsirkin" <mst@redhat.com>]

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.

-- 
MST