From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42541 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl3Ul-000729-Df for qemu-devel@nongnu.org; Thu, 03 Feb 2011 13:01:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pl3Ui-0007pw-4C for qemu-devel@nongnu.org; Thu, 03 Feb 2011 13:01:26 -0500 Received: from thoth.sbs.de ([192.35.17.2]:27888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pl3Uh-0007ng-JL for qemu-devel@nongnu.org; Thu, 03 Feb 2011 13:01:23 -0500 Message-ID: <4D4AED6D.4010009@siemens.com> Date: Thu, 03 Feb 2011 19:01:17 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] [0.14?][PATCH 3/4] ioapic: Prepare for base address relocation References: <0072079efad1c31da849cff7ad2cb426aeb6c29f.1296744934.git.jan.kiszka@siemens.com> <4D4AE360.1050905@siemens.com> <4D4AE95E.4070409@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Anthony Liguori , Gleb Natapov , "kvm@vger.kernel.org" , Marcelo Tosatti , "qemu-devel@nongnu.org" , Alexander Graf , Avi Kivity On 2011-02-03 18:54, Blue Swirl wrote: > On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka wrote: >> On 2011-02-03 18:36, Blue Swirl wrote: >>> On Thu, Feb 3, 2011 at 5:18 PM, Jan Kiszka wrote: >>>> On 2011-02-03 18:03, Blue Swirl wrote: >>>>> On Thu, Feb 3, 2011 at 2:55 PM, Jan Kiszka wrote: >>>>>> The registers of real IOAPICs can be relocated during runtime (via >>>>>> chipset registers). We don't support this yet, but qemu-kvm carries the >>>>>> current base address in its version 2 vmstate. >>>>>> >>>>>> To align both implementations for migratability, add the proper >>>>>> infrastructure to accept initial as well as updated base addresses and >>>>>> include the current address in the vmstate. This is done in a way that >>>>>> will also allow multiple IOAPICs in the future. >>>>> >>>>> Nack, the addresses should be device properties. >>>> >>>> Hmm.... we could make default_base_address a property. Will change that. >>>> But current_base_address is just the same as apicbase and can't be a >>>> property. >>> >>> Oh, right. What will current_base_address used for? Why can't board >>> just unmap IOAPIC from current address and remap it at the new >>> address? Then the device would not need to know its base address. >> >> The board could do this. The question is where we put this service, in >> the context if the IOAPIC as ioapic_set_base_address (compare to >> cpu_set_apic_base - which is buggy as it lacks sysbus_mmio_map) or into >> each and every board code. In the latter case, the boards would also be >> responsible for saving/restoring the address. > > How is the device relocated? Where are the chipset registers you mention? Intel's PIIX chipsets contain a register called APICBASE (but it means the IOAPIC), and that defines the location. The analogy in the APIC world is the MSR_IA32_APICBASE which we maintain via the APIC state. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux