From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] [0.14?][PATCH 3/4] ioapic: Prepare for base address relocation Date: Thu, 03 Feb 2011 20:25:12 +0100 Message-ID: <4D4B0118.3080904@siemens.com> References: <0072079efad1c31da849cff7ad2cb426aeb6c29f.1296744934.git.jan.kiszka@siemens.com> <4D4AE360.1050905@siemens.com> <4D4AE95E.4070409@siemens.com> <4D4AED6D.4010009@siemens.com> <4D4AFCA0.2080308@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "qemu-devel@nongnu.org" , Anthony Liguori , Gleb Natapov , Marcelo Tosatti , Alexander Graf , "kvm@vger.kernel.org" , Avi Kivity To: Blue Swirl Return-path: Received: from david.siemens.de ([192.35.17.14]:34283 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756537Ab1BCTZb (ORCPT ); Thu, 3 Feb 2011 14:25:31 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 2011-02-03 20:11, Blue Swirl wrote: > On Thu, Feb 3, 2011 at 7:06 PM, Jan Kiszka w= rote: >> On 2011-02-03 20:01, Blue Swirl wrote: >>> On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka = wrote: >>>> 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 runtim= e (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 pro= per >>>>>>>>>> infrastructure to accept initial as well as updated base add= resses 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 ch= ange 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 b= oard >>>>>>> just unmap IOAPIC from current address and remap it at the new >>>>>>> address? Then the device would not need to know its base addres= s. >>>>>> >>>>>> The board could do this. The question is where we put this servi= ce, 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 m= eans >>>> the IOAPIC), and that defines the location. The analogy in the API= C >>>> world is the MSR_IA32_APICBASE which we maintain via the APIC stat= e. >>> >>> In ICH10 the register is called OIC=E2=80=94Other Interrupt Control= Register >>> and the interesting bits APIC Range Select (ASEL). >>> >>> So actually PIIX should manage IOAPIC mapping, not board level. >> >> The point is we need ioapic_set_base_address logic in multiple place= s >> (once chipsets start to implement it). Better push it to a central p= lace >> from the beginning. Also the bit keeping. There is no difference to >> apicbase. >=20 > In that case, the function should be made inline version in ioapic.h. That still replicates the bit keeping. I don't see the benefit of moving it over, even less when we want to consolidate with a vmstate layout that is already in use. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60993 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pl4nu-0001ty-2U for qemu-devel@nongnu.org; Thu, 03 Feb 2011 14:25:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pl4ns-0006N3-By for qemu-devel@nongnu.org; Thu, 03 Feb 2011 14:25:17 -0500 Received: from david.siemens.de ([192.35.17.14]:30595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pl4ns-0006Mn-2z for qemu-devel@nongnu.org; Thu, 03 Feb 2011 14:25:16 -0500 Message-ID: <4D4B0118.3080904@siemens.com> Date: Thu, 03 Feb 2011 20:25:12 +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> <4D4AED6D.4010009@siemens.com> <4D4AFCA0.2080308@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 20:11, Blue Swirl wrote: > On Thu, Feb 3, 2011 at 7:06 PM, Jan Kiszka wro= te: >> On 2011-02-03 20:01, Blue Swirl wrote: >>> On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka w= rote: >>>> 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 ca= rries the >>>>>>>>>> current base address in its version 2 vmstate. >>>>>>>>>> >>>>>>>>>> To align both implementations for migratability, add the prope= r >>>>>>>>>> infrastructure to accept initial as well as updated base addre= sses 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 chan= ge 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 boa= rd >>>>>>> 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 al= so be >>>>>> responsible for saving/restoring the address. >>>>> >>>>> How is the device relocated? Where are the chipset registers you me= ntion? >>>> >>>> Intel's PIIX chipsets contain a register called APICBASE (but it mea= ns >>>> 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. >>> >>> In ICH10 the register is called OIC=E2=80=94Other Interrupt Control R= egister >>> and the interesting bits APIC Range Select (ASEL). >>> >>> So actually PIIX should manage IOAPIC mapping, not board level. >> >> The point is we need ioapic_set_base_address logic in multiple places >> (once chipsets start to implement it). Better push it to a central pla= ce >> from the beginning. Also the bit keeping. There is no difference to >> apicbase. >=20 > In that case, the function should be made inline version in ioapic.h. That still replicates the bit keeping. I don't see the benefit of moving it over, even less when we want to consolidate with a vmstate layout that is already in use. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux