[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: optional feature
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] Re: optional feature |
Date: |
Wed, 16 Sep 2009 09:08:59 -0500 |
User-agent: |
Thunderbird 2.0.0.23 (X11/20090825) |
Juan Quintela wrote:
up rtc version +1
add the two fields that we need (together with rtc-td-hack value)
And why this is better? You can't migrate old VM to new qemu even if you
don't use rtc-td-hack on new one.
I think the difference between us is:
- is rtc-td-hack a hack that should only be used for some users
- it is a valid rtc feature that should be available to everybody
- it is independent, or it needs an rtc to have any value.
We need a single table that contains the full state for the device.
Many devices will have knobs. There are two likely types of knobs:
1) something that indicates how an array of state is going to be
2) a boolean that indicates whether a portion of state is valid
rtc-td falls into the second category. It makes sense to me that the
table state would contain a boolean to indicate whether a given set of
state was valid. You may need a grouping mechanism for this. It
probably makes sense to do this as separate tables. For instance,
.fields = (VMStateField []) {
VMSTATE_BOOL(td_hack, RTCState, (VMStateField[]){
VMSTATE_INT32(irq_coalesced, RTCState),
VMSTATE_INT32(period, RTCState),
VMSTATE_END_OF_LIST()}),
}
If we can't maintain backwards compatibility using this approach (we
definitely can't for rtc-td) then we'll just have to live with that.
I also think arrays should be expressed like this FWIW. Today we have
explicit typed arrays. I would rather see:
.fields = (VMStateField []) {
VMSTATE_ARRAY(nirq, PCIBus, (VMStateField[]) {
VMSTATE_INT32(irq_count[0], PCIBus),
VMSTATE_END_OF_LIST()}),
}
- [Qemu-devel] Re: optional feature, (continued)
- [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- [Qemu-devel] Re: optional feature, Gleb Natapov, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- [Qemu-devel] Re: optional feature, Gleb Natapov, 2009/09/16
- [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- Re: [Qemu-devel] Re: optional feature,
Anthony Liguori <=
- Re: [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- [Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16
- [Qemu-devel] Re: optional feature, Juan Quintela, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
- Re: [Qemu-devel] Re: optional feature, Anthony Liguori, 2009/09/16
[Qemu-devel] Re: optional feature, Michael S. Tsirkin, 2009/09/16