[Top][All Lists]
[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:27:53 +0100 |
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
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, (continued)
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, David Gibson, 2012/11/22
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Michael S. Tsirkin, 2012/11/23
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, David Gibson, 2012/11/23
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Michael S. Tsirkin, 2012/11/23
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Alexander Graf, 2012/11/23
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Michael S. Tsirkin, 2012/11/23
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Alexander Graf, 2012/11/23
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Michael S. Tsirkin, 2012/11/23
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges,
Alexander Graf <=
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, David Gibson, 2012/11/25
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Michael S. Tsirkin, 2012/11/21
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, David Gibson, 2012/11/20
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Alexander Graf, 2012/11/21
- Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges, Michael S. Tsirkin, 2012/11/21
[Qemu-devel] [PATCH 10/12] pseries: Update SLOF for NVRAM support, David Gibson, 2012/11/12
Re: [Qemu-devel] [0/12] Pending pseries patches, Alexander Graf, 2012/11/19