qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 24/36] vmstate: port arm cpu


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH 24/36] vmstate: port arm cpu
Date: Wed, 21 Mar 2012 18:16:51 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux)

Andreas Färber <address@hidden> wrote:
> Am 19.03.2012 23:57, schrieb Juan Quintela:
>> Use one subsection for each feature.  This means that we don't need to
>> bump the version field each time that a new feature gets introduced.
>> 
>> Introduce cpsr_vmstate field, as I am not sure if I can "use"
>> uncached_cpsr for saving state.
>> 
>> Signed-off-by: Juan Quintela <address@hidden>
>
> As stated previously, I still think we should hold off converting the
> ARM CPU to VMState until the cp15 rework by Peter takes on shape.

This converts all cpus to vmstate.  Conversion of cp15 is indiferent of
vmstate.  Basically we will need to send something like one array of 
pairs: [(register_id, value)], and have some validation before we
receive it.

Notice that something like that is also needed for x86 MSR's, just now
we are sending them ad-hoc, but it would be great to do something like:
- notice what msr's have been read/write by guest
- just send that msr's.
- maintain backwards compatibility is going to be a mess, but that don't
  affect arm at this moment.

I guess that cp15 registers have some similar meaning (they are
optional, and not all of them have been touched by the guest).  But I
still haven't a good idea on how to handle it.

> On another matter, had you prefixed this patch with "target-arm: "
> rather than hiding that essential keyword where my mailer cuts it off,
> it would be much easier to find in this series than amidst lots of
> "vmstate: " patches.

clearly, we need: keywords in each patch, in the gmail sense.  one patch
can be related to several subsystems.  general topic here was vmstate,
but I fully agree that if I had used target-foo: as starting it would
have been as good (just for a different definition of good).

Thanks, Juan.



reply via email to

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