On 2011-10-18 10:17, Jan Kiszka wrote:
> On 2011-10-18 09:58, Daniel P. Berrange wrote:
>> On Tue, Oct 18, 2011 at 03:15:29PM +0800, Wen Congyang wrote:
>>> Hi, Jan Kiszka
>>>
>>> At 10/10/2011 05:34 PM, Jan Kiszka Write:
>>>> On 2011-10-10 11:02, Daniel P. Berrange wrote:
>>>>> On Mon, Oct 10, 2011 at 08:52:08AM +0200, Jan Kiszka wrote:
>>>
>>>>
>>>> Run gdb with "set debug remote 1" and watch the communication, it is not
>>>> that complex. But a dump command is probably simpler for those
>>>> scenarios, I agree.
>>>
>>> I have implemented the command dump and reuse migration's code. But I meet
>>> a problem
>>> when I test it.
>>>
>>> My qemu-kvm's tree is not updated about 2 months ago, because kernel.org is
>>> down, and
>>> I forgot to pull from github.
>>>
>>> After I pull it from github, I find the following changes:
>>> @@ -1523,9 +1523,7 @@ static void
>>> assigned_dev_unregister_msix_mmio(AssignedDevice *dev)
>>>
>>> static const VMStateDescription vmstate_assigned_device = {
>>> .name = "pci-assign",
>>> - .fields = (VMStateField []) {
>>> - VMSTATE_END_OF_LIST()
>>> - }
>>> + .unmigratable = 1,
>>> };
>>>
>>> static void reset_assigned_device(DeviceState *dev)
>>>
>>> Why do you remove fields from vmstate_assigned_device?
>>> It is useful for dump because it does not check unmigratable. If
>>> vmstate_assigned_device
>>> does not contain .fields, qemu will crash in vmstate_save_state().
>>
>> Given that '.fields' is allowed to be NULL for some devices, I'd say
>> even for normal migration, QEMU should be checking for NULL in the
>> vmstate_save_state() code. This would prevent QEMU crashes in the case
>> where someone removed the .unmigratable member, but forgot to add back
>> a .fields member.
>
> That crash wouldn't be bad because removinb unmigratable without adding
> proper fields is almost always a bug.
Err, s/almost//.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
