From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: live migration between kernel/user irqchip Date: Thu, 19 Jul 2007 17:24:50 +0300 Message-ID: <469F7432.5050806@qumranet.com> References: <10EA09EFD8728347A513008B6B0DA77A01CBE67A@pdsmsx411.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "Dong, Eddie" Return-path: In-Reply-To: <10EA09EFD8728347A513008B6B0DA77A01CBE67A-wq7ZOvIWXbNpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Dong, Eddie wrote: > Avi Kivity wrote: > >> Dong, Eddie wrote: >> >>> When thinking about live migration support for in kernel irqchip, one >>> question comes out which need to be solved first: >>> Do we need to support live migration among user level irqchip and >>> kernel level? >>> >> Yes. >> >> >>> If the answer is yes, kernel level irqchip must keep same state >>> with user level, i.e. if Qemu changes the pic/apic/ioapic state >>> definition, we need to do corresponding changes too, otherwise >>> kernel side can stay as it is. >>> >>> >> The qemu state mimics the device state and should be independent of >> implementation details. If the qemu state is added too, this most >> likely indicates a but that needs to be fixed in kvm as well. >> >> The best way to do live migration is to copy the kernel state into the >> qemu device model, and let qemu do state serialization. This ensures >> > > "copy" means we define some device "state" both in kernel & user. > I.e. kernel use user level state definition. > Sorry, I don't understand. Here's apic_save(), for example: static void apic_save(QEMUFile *f, void *opaque) { APICState *s = opaque; int i; qemu_put_be32s(f, &s->apicbase); qemu_put_8s(f, &s->id); qemu_put_8s(f, &s->arb_id); qemu_put_8s(f, &s->tpr); qemu_put_be32s(f, &s->spurious_vec); qemu_put_8s(f, &s->log_dest); qemu_put_8s(f, &s->dest_mode); for (i = 0; i < 8; i++) { qemu_put_be32s(f, &s->isr[i]); qemu_put_be32s(f, &s->tmr[i]); qemu_put_be32s(f, &s->irr[i]); } for (i = 0; i < APIC_LVT_NB; i++) { qemu_put_be32s(f, &s->lvt[i]); } qemu_put_be32s(f, &s->esr); qemu_put_be32s(f, &s->icr[0]); qemu_put_be32s(f, &s->icr[1]); qemu_put_be32s(f, &s->divide_conf); qemu_put_be32s(f, &s->count_shift); qemu_put_be32s(f, &s->initial_count); qemu_put_be64s(f, &s->initial_count_load_time); qemu_put_be64s(f, &s->next_time); qemu_put_timer(f, s->timer); } Do you see state here that does not exist in the kernel? Or kernel state that is missing from here? ->timer and ->next_time may be non-trivial, but both are needed. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/