[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v2 6/6] hw: arm_gic_kvm: Add KVM VGIC save/r
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [RFC PATCH v2 6/6] hw: arm_gic_kvm: Add KVM VGIC save/restore logic |
Date: |
Tue, 15 Oct 2013 11:35:46 +0100 |
On 27 September 2013 09:11, Alex Bennée <address@hidden> wrote:
>
> address@hidden writes:
>
>> Save and restore the ARM KVM VGIC state from the kernel. We rely on
> <snip>
>>
>> static const VMStateDescription vmstate_gic = {
>> .name = "arm_gic",
>> - .version_id = 6,
>> - .minimum_version_id = 6,
>> + .version_id = 7,
>> + .minimum_version_id = 7,
>> .pre_save = gic_pre_save,
>> .post_load = gic_post_load,
>> .fields = (VMStateField[]) {
>
> Does this mean QEMU and Kernel need to be kept in lock-step for
> compatibility?
No. This patch is a little confusing because it's both adding
the new fields and also adding the save/restore support, but
once we have the data structures and vmstate in QEMU holding
all the state the kernel needs, there shouldn't be any need
to update the vmstate in a backwards-incompatible way.
>>
>> +//#define DEBUG_GIC_KVM
>> +
>> +#ifdef DEBUG_GIC_KVM
>> +static const int debug_gic_kvm = 1;
>> +#else
>> +static const int debug_gic_kvm = 0;
>> +#endif
>> +
>> +#define DPRINTF(fmt, ...) do { \
>> + if (debug_gic_kvm) { \
>> + printf("arm_gic: " fmt , ## __VA_ARGS__); \
>> + } \
>> + } while (0)
>> +
>
> Shouldn't we be using QEMU logging framework for this? Also for the
> fprintfs later on.
No, these are debug printfs, not things which would be interesting
to the average user/person trying to debug a guest. We don't
have a particularly clean framework for compile time
enabled debug printfs, so 'some random macro in each individual
file' is the current approach.
-- PMM
- Re: [Qemu-devel] [RFC PATCH v2 6/6] hw: arm_gic_kvm: Add KVM VGIC save/restore logic,
Peter Maydell <=