qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBN


From: Alexander Graf
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges
Date: Fri, 23 Nov 2012 15:03:24 +0100

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]