qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-1.4] pc: tag apic as overlap region


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH for-1.4] pc: tag apic as overlap region
Date: Tue, 19 Feb 2013 17:23:45 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2013-02-19 17:20, Peter Maydell wrote:
> On 19 February 2013 16:05, Jan Kiszka <address@hidden> wrote:
>> On 2013-02-19 16:54, Peter Maydell wrote:
>>> On 19 February 2013 15:51, Jan Kiszka <address@hidden> wrote:
>>>> On 2013-02-19 16:20, Michael S. Tsirkin wrote:
>>>>>      qdev_init_nofail(dev);
>>>>>      d = SYS_BUS_DEVICE(dev);
>>>>> -    sysbus_mmio_map(d, 0, 0xfec00000);
>>>>> +    /* APIC overlaps the PCI window. */
>>>>> +    sysbus_mmio_map_overlap(d, 0, 0xfec00000, 1000);
>>>>
>>>> That's the IOAPIC, not the APIC. If you mean the IOAPIC, APIC and HPET
>>>> would require higher prio, too. But I suppose this is really about the
>>>> APIC and its special priority due to CPU-local access dispatching, right?
>>>
>>> Is this a proposed minimally invasive patch for 1.4 with a
>>> different approach (possibly involving reworking things with
>>> a better managed set of container regions) for master, or
>>> is this the planned fix for master too?
>>
>> I'm not yet sure we need any overhaul at all. If hardware prioritizes
>> certain windows like APIC, IOAPIC, HPET over PCI device mappings, then
>> we can already express this today - we just need to do it.
> 
> Yes, indeed, but there are different ways to do it with the
> API we have at the moment (the patch above being one way).
> On reflection it's probably a reasonable approach since we
> can't currently set up CPUs to dispatch memory accesses to
> an arbitrary MemoryRegion.[*]
> 
> [*] by which I mean that really the correct model for this
> would be something like:
>  the CPU cores live inside a QOM container object which also
>  has the CPU-local devices like the IOAPIC &c inside it.
>  This container has a container memory region which is set
>  up as "background region == the MR which the board model
>  passes to us; overlaid at higher priority == CPU-local devices",
>  and that container MR is then what you pass to the CPU cores
>  as their view of the address space.
> I don't suppose we'll go down that path until we have a compelling
> reason to implement multiple bus masters with different views
> of the address space, though.

Well, the APIC (not the IOAPIC) is already a reason to implement such a
feature. We still do not properly support it, means (in user space) we
do not allow the guest to remap its APIC to different addresses for
different CPUs. But we got along with that for quite a while now. So no
need to fix it in a hurry.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]