[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 0/2] PC system flash support
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v8 0/2] PC system flash support |
Date: |
Wed, 30 Nov 2011 09:38:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
Markus Armbruster <address@hidden> writes:
> Avi Kivity <address@hidden> writes:
>
>> On 11/29/2011 09:03 AM, Jordan Justen wrote:
>>> On Mon, Nov 28, 2011 at 02:28, Avi Kivity <address@hidden> wrote:
>>> > On 11/28/2011 04:26 AM, Jordan Justen wrote:
>>> >> Enable flash emulation in a PC system using pflash_cfi01.
>>> >
>>> > The new memory layout should be made conditional on the machine type (-M
>>> > pc-1.1 or later) to allow migration from/to pc-1.0 and earlier.
>>> >
>>> > Memory layout in this context are the names of memory ranges given to
>>> > memory_region_init_ram(), sizes, and locations. Also, the flash
>>> > interface should not be there for older machines.
>>>
>>> Is this the right way to go about it?
>>> 1. Create a new pc-sysfw qdev
>>> 2. Use a flash property in pc_piix.c to selectively enable the flash
>>>
>>> Or, is there an easier or better way to say pc > pc-1.0?
>>
>> No idea, copying some qdev people.
>>
>>> How do I enable "migration from/to pc-1.0 and earlier"? It seems like
>>> some code will need to shuttle the data (rom <=> pflash). Can you
>>> point me an an example?
>>
>> It should be completely transparent, so long as you instantiate a ROM
>> for <= pc-1.0 (say based on a property) and flash for >= pc-1.1.
>>
>> One way to verify is to to 'info qdev' and 'info mtree' with qemu-1.0
>> and qemu-1.1 -M pc-1.0, and see that you get the same results.
>
> Gerd created the compatibility machinery (commit b6b61144), and I'm not
> really familiar with it. But I can give it a try.
>
> Our tool to configure devices is qdev properties.
>
> The device defines property default values. The board can override
> them, with QEMUMachine member compat_props.
If you need more than just configuring a device differently, you
probably need to hack the board init method. Check out commit 0ec329da
for an example. Works roughly like this:
* Add suitable parameter to pc_init1()
* Change pc_init_pci() to pass the "new behavior on" argument.
* Define pc_init_pci_no_kvmclock() like pc_init_pci(), except pass the
"new behavior off" argument. Change old boards to use it.
[...]