Re: [Qemu-devel] KVM call agenda for October 11th

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

 



On 10/11/2011 08:27 AM, Juan Quintela wrote:
Avi Kivity<avi@xxxxxxxxxx>  wrote:
On 10/10/2011 01:35 PM, Juan Quintela wrote:
Hi

Please send in any agenda items you are interested in covering.


Subsections, version numbers, migration to older releases.

Subsections
-----------

- Current subsections are a mess (TM).  The idea was to only have them
at the very end of sections.  So it was clear that it was a section
(start with QEMU_VM_SECTION_START), or a subsection of this section,
(start with QEMU_VM_SUBSECTION).  As you can see, there is no possible
ambiguity.

Guess what happened?  We needed subsections in the middle of the struct,
where we can't warantee what cames after (that can be
QEMU_VM_SUBSECTION).

My last migration "subsection detection fix" fixes this in the majority
of the cases, but you can probably do a case by hand where it happens.

Back to the beggining, Avi wanted/wants that subsections are just normal
sections with a "funny" name ("section_name/subsection_name"), requiring
FIFO ordering or something like that.  So far, so good, but we still
have the problem that:
a- we need to assure that ordering is right (do-able)
b- we need to assure that "post-load" functions are done in the right
    order (also do-able)
c- we need to be able from toplevel where we only have pointers to the
    general state to find the correct "substruct" pointer that this
    subsection refers to.  This is kind of complicated :-(

My sugestion/plan:
- integrate my migration detection fix on upstream + stable

- port all current subsections to avi approach to see about how feasible
   is.  If IDE subsections can be made to work, everything else should be
   doable.

Version numbers
---------------

What to do here?  Basically we have been able to integrate all changes
so far using subsections (some of them in a non-trivial way, thought).

Last one is the change proposed on wavcapture, I stated some ideas, but
got no answer from the author.  Basically he did an incompatible change
on the driver, and I can't see a trivial way to make it compatible.
Chanels used to be either output/input, and now they need to be both, so
he duplicated the channels.

Migration to older releases
---------------------------

Our test framework for that is inexistent.  That is the more important
issue for this to work.  Problem is that nobody really knows how to do
it.

I've been thinking about it this morning. I think it's solvable. We need to be able to save off the qdev construction properties right before init. This is just a matter of storing a list of strings. Then we need a qdev_torture function that will save the device state (will require a dummy QEMUFile that saves to memory). We then need to invoke destruction w/o actually freeing the memory of the device. We should then zero out the device memory.

We then need to run through qdev creation, setting properties based on the saved construction properties. Then we should init and invoke the device's reset function. Finally we can pass the dummy QEMUFile to the device's load function (or vmstate).

I'll take a look at implementing this today. I think it'll be a bit hairy but it looks doable to me.

Regards,

Anthony Liguori


One of the ideas is to run machine, stop, save everything, reload, and
continue.  Or doing it in a loop for each device, but so far, they
haven't moved for the "design" phase (for lack of a better word to
describe "something that is on someone head and needs to be done").

Once here, more migration issues
--------------------------------

- VMState finish: Still on ToDo list, once my two series on the list is
   integrated, I expect to work on virtio + other cpus.  No way this is
   going to be done for the 15th, perhaps one week after that.

- migration thread: another thing that I am going to look at, in
   paraller with previous stuff.

Patches on RHEL not in qemu.git
-------------------------------

- qcow2 consistence for migration: we need to reload qcow2 headers after
   migration, should be an easy case of split open in open + reload.  We
   have decided that we only support migration with cache=none, so part
   of the series is not needed.

- Huge memory machines: Last time I proposed the series, Anthony agreed
   with everything except the last patch (that was a bandaid, I agree).
   Added with the migration thread descrived before, we should be done on
   that department.

Changing the protocol?
---------------------

Except if someone appears and found an use for the new protocol, I will
stay away for changing it.  Things that need to be done once that we
change the protocol in an incopmatible way:

- send command line arguments through the migration channel, at least
   put support for it there.  Needs qdev/QOM or whatever changes first.

- put sections size/end markers.

- fix the arrays mess.  Basically we need to send things like:
    total size of array (think malloc)
    number of elements used (how many we sent)
    start: (we don't always sent data from the start)
    circular buffers:  At the moment, we use some arrays as "circular
    buffers", and we just send to the beginning.
    this is from top of memory, going through all the array users will
    make things clearer.
    index of array, we have for index everything, int8_t, uint8_t,
    int16_t, uint16_t, int32_t, uint32_t.  We should just use one type
    for index, and make all our arrays simpler.

- bitmaps: we need a type to sent bitmaps, period.

- remove all the warts that we don't need anymore due to backward
   compatibility.

- cpus: specially x86_*. Our format support for x86 is a mess, things
   like: - how to store doubles (at least 4 formats)
         - a generic way of sending a list of MSR's is needed.  We are
           going to need more MSR's in the future, and we are having a
           new subsection/version for each new MSR.  To make things
           worse, we have to "resync" state between KVM<->  qemu after
           each MSR is loaded.  Something better is needed.

As stated in previous discussions, without solving all this problems it
makes no sense if you don't explore all of them, as probably each of
them requires changes in the protocol.

Later, Juan.


--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux