On 11/09/2011 07:43 PM, Anthony Liguori wrote:
>> Every MemoryRegion field in qemu today is either immutable or slaved to
>> another register. We could have a system to annotate every field, but
>> it's pointless.
>
>
> If I'm writing a device and doing save/restore and I happen to use a
> MemoryR
On 11/09/2011 09:56 AM, Avi Kivity wrote:
On 11/09/2011 05:49 PM, Anthony Liguori wrote:
VMSTATE_MEMORY_REGION(integratorcm, flash),
Therefore this line is 100% redundant.
Yes, but the problem is that it's not obvious *why*. That's what I'm
trying to get at here. If you have a VMSTATE_M
On 9 November 2011 15:56, Avi Kivity wrote:
> On 11/09/2011 05:49 PM, Anthony Liguori wrote:
>> Avi wrote:
>>> clear-on-read mask
>>
>> Really? Is that all that common outside of PCI config?
>
> Yes, ISR fields often have it (like virtio).
Write-one-to-clear is pretty popular too.
-- PMM
On 11/09/2011 05:49 PM, Anthony Liguori wrote:
>
>>> VMSTATE_MEMORY_REGION(integratorcm, flash),
>>
>> Therefore this line is 100% redundant.
>
>
> Yes, but the problem is that it's not obvious *why*. That's what I'm
> trying to get at here. If you have a VMSTATE_MEMORY_REGION() that has
> all of
On 11/09/2011 09:05 AM, Avi Kivity wrote:
On 11/09/2011 04:40 PM, Anthony Liguori wrote:
typedef struct {
SysBusDevice busdev;
uint32_t memsz;
MemoryRegion flash;
bool flash_mapped;
Both flash.has_parent and flash_mapped are slaved to a bit of one of the
registers below.
On 11/09/2011 05:20 PM, Peter Maydell wrote:
> From a really quick glance at Avi's memory/mutators branch I think
> the long term plan would be that rather than mapping/unmapping the
> region we just call memory_region_set_enabled() which would cope
> happily with being asked to enable an already-e
On 9 November 2011 15:05, Avi Kivity wrote:
> On 11/09/2011 04:40 PM, Anthony Liguori wrote:
>>
>> typedef struct {
>> SysBusDevice busdev;
>> uint32_t memsz;
>> MemoryRegion flash;
>> bool flash_mapped;
>
> Both flash.has_parent and flash_mapped are slaved to a bit of one of the
>
On 11/09/2011 04:40 PM, Anthony Liguori wrote:
>
> typedef struct {
> SysBusDevice busdev;
> uint32_t memsz;
> MemoryRegion flash;
> bool flash_mapped;
Both flash.has_parent and flash_mapped are slaved to a bit of one of the
registers below.
> uint32_t cm_osc;
> uint32_t c
On 11/08/2011 11:19 AM, Avi Kivity wrote:
On 11/08/2011 05:32 PM, Anthony Liguori wrote:
If the question is, how do we restore the immutable state, that should
be happening as part of device creation, no?
The way I see it, we create a link between some device state (a
register) and a memory
On 11/08/2011 05:32 PM, Anthony Liguori wrote:
>
>>>
>>> If the question is, how do we restore the immutable state, that should
>>> be happening as part of device creation, no?
>>>
The way I see it, we create a link between some device state (a
register) and a memory API field (like the o
On 11/08/2011 09:15 AM, Avi Kivity wrote:
On 11/08/2011 05:04 PM, Anthony Liguori wrote:
What state is that? Some devices have fixed size, offset, parent, and
enable/disable state (is there a word for that?), so there is no state
that needs to be transferred. For other devices this is all dyna
On 11/08/2011 05:04 PM, Anthony Liguori wrote:
>
> There's no code generation in QOM :-)
>
> This just comes down to how we do save/restore. We white list things
> we care about. We should move to a model where we save/restore
> everything (preferably via code generation), and then black
> list/t
On 11/08/2011 08:38 AM, Avi Kivity wrote:
On 11/08/2011 03:50 PM, Anthony Liguori wrote:
We agree, the only difference is in what "core" refers to. I don't want
memory.c do become intermingled with everything else. It should be in a
separate layer. Devices would then talk to this layer, and n
On 11/08/2011 03:50 PM, Anthony Liguori wrote:
>> We agree, the only difference is in what "core" refers to. I don't want
>> memory.c do become intermingled with everything else. It should be in a
>> separate layer. Devices would then talk to this layer, and not to the
>> gluing by themselves as
On 11/08/2011 06:38 AM, Avi Kivity wrote:
On 11/08/2011 02:30 PM, Peter Maydell wrote:
On 8 November 2011 12:21, Avi Kivity wrote:
On 11/08/2011 02:15 PM, Peter Maydell wrote:
This needs to be in the MemoryRegion core implementation, please.
Right; see the memory/mutators branch. I plan to
On 8 November 2011 12:38, Avi Kivity wrote:
> On 11/08/2011 02:30 PM, Peter Maydell wrote:
>> On 8 November 2011 12:21, Avi Kivity wrote:
>> > On 11/08/2011 02:15 PM, Peter Maydell wrote:
>> >> This needs to be in the MemoryRegion core implementation, please.
>> >
>> > Right; see the memory/mutat
On 11/08/2011 02:30 PM, Peter Maydell wrote:
> On 8 November 2011 12:21, Avi Kivity wrote:
> > On 11/08/2011 02:15 PM, Peter Maydell wrote:
> >> This needs to be in the MemoryRegion core implementation, please.
> >
> > Right; see the memory/mutators branch. I plan to push this as soon as
> > ever
On 8 November 2011 12:21, Avi Kivity wrote:
> On 11/08/2011 02:15 PM, Peter Maydell wrote:
>> This needs to be in the MemoryRegion core implementation, please.
>
> Right; see the memory/mutators branch. I plan to push this as soon as
> everything is converted.
OK, then this save/restore patch sh
On 11/08/2011 02:15 PM, Peter Maydell wrote:
> >>
> >> Avi, ping? I'm still interested in the answer to this question.
> >
> > Sorry, missed this. Yes, you need to ensure the memory region mapping
> > reflects flash_mapped.
>
> This needs to be in the MemoryRegion core implementation, please.
Righ
2011/11/8 Benoît Canet :
>
> flash_mapped reflect the bit 2 of a control register.
> Peter, does this patch look better ?
See my reply to Avi; I'd rather we fixed the MemoryRegion
API rather than working around it in devices with postload hooks.
thanks
-- PMM
On 8 November 2011 06:33, Avi Kivity wrote:
> On 11/08/2011 04:07 AM, Peter Maydell wrote:
>> 2011/10/26 Peter Maydell :
>> > On 25 October 2011 12:09, Benoît Canet wrote:
>> >> +static const VMStateDescription vmstate_integratorcm = {
>> >> + .name = "integratorcm",
>> >> + .version_id = 1
flash_mapped reflect the bit 2 of a control register.
Peter, does this patch look better ?
commit 2fa7b11ee2b2532d00056d6bbc928c5162925e1d
Author: Benoît Canet
Date: Mon Oct 24 14:39:26 2011 +0200
integratorcp: convert integratorcm to VMState
Signed-off-by: Benoit Canet
diff --git
On 11/08/2011 04:07 AM, Peter Maydell wrote:
> 2011/10/26 Peter Maydell :
> > On 25 October 2011 12:09, Benoît Canet wrote:
> >> +static const VMStateDescription vmstate_integratorcm = {
> >> +.name = "integratorcm",
> >> +.version_id = 1,
> >> +.minimum_version_id = 1,
> >> +.mini
2011/10/26 Peter Maydell :
> On 25 October 2011 12:09, Benoît Canet wrote:
>> +static const VMStateDescription vmstate_integratorcm = {
>> + .name = "integratorcm",
>> + .version_id = 1,
>> + .minimum_version_id = 1,
>> + .minimum_version_id_old = 1,
>> + .fields = (VMStateField[])
On 25 October 2011 12:09, Benoît Canet wrote:
> +static const VMStateDescription vmstate_integratorcm = {
> + .name = "integratorcm",
> + .version_id = 1,
> + .minimum_version_id = 1,
> + .minimum_version_id_old = 1,
> + .fields = (VMStateField[]) {
> + VMSTATE_UINT32(memsz,
Signed-off-by: Benoit Canet
---
hw/integratorcp.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index 9a289b4..e8d8d67 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -34,6 +34,29 @@ typedef struct
26 matches
Mail list logo
