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. 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
