qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH RFC] Mark a device as non-migratable


From: Cam Macdonell
Subject: Re: [Qemu-devel] Re: [PATCH RFC] Mark a device as non-migratable
Date: Wed, 16 Jun 2010 22:18:21 -0600

On Wed, Jun 16, 2010 at 6:34 AM, Anthony Liguori <address@hidden> wrote:
> On 06/16/2010 12:05 AM, Cam Macdonell wrote:
>>
>> On Tue, Jun 15, 2010 at 4:33 PM, Anthony Liguori<address@hidden>
>>  wrote:
>>
>>>
>>> On 06/15/2010 05:26 PM, Cam Macdonell wrote:
>>>
>>>>
>>>> On Tue, Jun 15, 2010 at 10:32 AM, Anthony Liguori<address@hidden>
>>>>  wrote:
>>>>
>>>>
>>>>>
>>>>> On 06/15/2010 11:16 AM, Cam Macdonell wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> How does this look for marking the device as non-migratable?  It adds
>>>>>> a
>>>>>> field
>>>>>> 'no_migrate' to the SaveStateEntry and tests for it in vmstate_save.
>>>>>>  This
>>>>>> would
>>>>>> replace anything that touches memory.
>>>>>>
>>>>>> Cam
>>>>>>
>>>>>> ---
>>>>>>  hw/hw.h  |    1 +
>>>>>>  savevm.c |   32 +++++++++++++++++++++++++++++---
>>>>>>  2 files changed, 30 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/hw/hw.h b/hw/hw.h
>>>>>> index d78d814..7c93f08 100644
>>>>>> --- a/hw/hw.h
>>>>>> +++ b/hw/hw.h
>>>>>> @@ -263,6 +263,7 @@ int register_savevm_live(const char *idstr,
>>>>>>                           void *opaque);
>>>>>>
>>>>>>  void unregister_savevm(const char *idstr, void *opaque);
>>>>>> +void mark_no_migrate(const char *idstr, void *opaque);
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> I'm not thrilled with the name but the functionality is spot on.  I
>>>>> lack
>>>>> the
>>>>> creativity to offer a better name suggestion :-)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Anthony Liguori
>>>>>
>>>>>
>>>>
>>>> Hmmm, in working on this it seems that the memory (from
>>>> qemu_ram_map()) is still attached even when the device is removed
>>>> (which causes migration to fail because there is an unexpected
>>>> memory).
>>>>
>>>> Is something like cpu_unregister_physical_memory()/qemu_ram_free()
>>>> needed?
>>>>
>>>>
>>>
>>> Yes.  You need to unregister any memory that you have registered upon
>>> device
>>> removal.
>>>
>>
>> Is there an established way to achieve this?  I can't seem find
>> another device that unregisters memory registered with
>> cpu_register_physical_memory().  Is something like
>> cpu_unregister_physical_memory() needed?
>>
>
> cpu_register_physical_memory(IO_MEM_UNASSIGNED).
>
> If you look at pci.c, you'll see that it automatically unregisters any
> mapped io regions on remove.
>

It appears that the 'peer' migration won't work until memory hotplug
is supported, correct?  AFAICT the memory sizes will not match between
the source and destination VMs after the device is removed and the
memory system currently doesn't support gaps.  A technique similar to
my patch for non-migratable memory would be needed to mark free'd
memory pages without Alex's patches in.

For the purposes of my patch, can it be merged without the 'peer' case
(pending Alex's patches and hotplug)?

Thanks,
Cam



reply via email to

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