[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH] mac99: Bring memory layout closer to real hardwar
From: |
Alexander Graf |
Subject: |
Re: [Qemu-ppc] [PATCH] mac99: Bring memory layout closer to real hardware |
Date: |
Mon, 14 Apr 2014 23:42:01 +0200 |
> Am 14.04.2014 um 23:29 schrieb Mark Cave-Ayland <address@hidden>:
>
> On 14/04/14 08:21, Alexander Graf wrote:
>
>>> I agree with adjusting the mac99 model instead of starting from
>>> scratch not only because it's less work but also because there's not
>>> much point in keeping a machine called mac99 that does not match any
>>> real Mac. I'll send my current patch with minimal changes to make the
>>> memory layout better match what's seen on PowerMac3,1.
>>
>> I can't apply that without changing OpenBIOS as well. And OpenBIOS
>> doesn't get the memory layout from the machine, it only gets an
>> identifier that says "I'm machine numer X, use me".
>>
>> So we would have to add a new machine type in fw_cfg for this machine,
>> as otherwise we would render newer OpenBIOS incompatible with older QEMU
>> at which point we can as well just call the whole thing a new machine.
>
> There is actually precedent for making simultaneous OpenBIOS and QEMU
> changes; there have been a couple of times where the fw_cfg interface has
> changed in the past and Blue has done simultaneous commits in order to
> facilitate the update. Given that OpenBIOS doesn't really have a stable
> branch as such, I'd be okay with another coordinated update during a quiet
> OpenBIOS spell in the QEMU 2.1 development period.
If we get it done in one go and there is definite gain, sure. But I won't do
this for thr sake of moving 5% closer to real hardware without getting there
for real. I don't want to go through this mess again in a few months.
If we break compatibility, I would also like to *break* compatibility with real
Macs by moving the nvram to a 64k boundary, so that the mac99 machine works
with kvm on 64k page sized hosts.
Alex