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
