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:04:51 +0300 Message-ID: <469F6F83.3060700@qumranet.com> References: <10EA09EFD8728347A513008B6B0DA77A01CBE671@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: <10EA09EFD8728347A513008B6B0DA77A01CBE671-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: > 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 compatibility. -- 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/