From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [0.14?][PATCH 3/4] ioapic: Prepare for base address relocation Date: Thu, 03 Feb 2011 20:06:08 +0100 Message-ID: <4D4AFCA0.2080308@siemens.com> References: <0072079efad1c31da849cff7ad2cb426aeb6c29f.1296744934.git.jan.kiszka@siemens.com> <4D4AE360.1050905@siemens.com> <4D4AE95E.4070409@siemens.com> <4D4AED6D.4010009@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Anthony Liguori , Gleb Natapov , "kvm@vger.kernel.org" , Marcelo Tosatti , "qemu-devel@nongnu.org" , Alexander Graf , Avi Kivity To: Blue Swirl Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 2011-02-03 20:01, Blue Swirl wrote: > On Thu, Feb 3, 2011 at 6:01 PM, Jan Kiszka wro= te: >> On 2011-02-03 18:54, Blue Swirl wrote: >>> On Thu, Feb 3, 2011 at 5:43 PM, Jan Kiszka w= rote: >>>> 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 (v= ia >>>>>>>> chipset registers). We don't support this yet, but qemu-kvm carr= ies 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 address= es and >>>>>>>> include the current address in the vmstate. This is done in a wa= y 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 i= nto >>>> 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 ment= ion? >> >> 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. >=20 > In ICH10 the register is called OIC=E2=80=94Other Interrupt Control Reg= ister > and the interesting bits APIC Range Select (ASEL). >=20 > 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 place from the beginning. Also the bit keeping. There is no difference to apicbase. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux