qemu-devel
[Top][All Lists]
Advanced

[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.

[...]



reply via email to

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