Re: 64k host kernel, QEMU Foundation Model GICV issue

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

 



On Mon, Dec 15 2014 at 11:01:38 PM, Mario Smarduch <m.smarduch@xxxxxxxxxxx> wrote:
> On 12/15/2014 02:37 PM, Peter Maydell wrote:
>> On 15 December 2014 at 22:14, Mario Smarduch <m.smarduch@xxxxxxxxxxx> wrote:
>>> Hi Peter,
>>>    you may be aware of this alrady, but on 64K page host you can't
>>> boot a Guest, QEMU doesn't map GICC at identical offset of GICV on
>>> Foundation model which is 0x2c02f000.
>>>
>>> Luckily Marc made me aware of this (and his kernel fix), otherwise
>>> you can't bring any Guest up. Hard coding these changes worked.
>>>
>>> [VIRT_CPUPERIPHS] = { 0x08000000, 0x00030000 },
>>> [VIRT_GIC_CPU] =    { 0x0801f000, 0x00020000 },
>>>
>>> It appears like GICV offset should be dynamically discovered
>>> and map updated to appropriate offset to get around this.
>> 
>> Yeah, it's one of those issues that's sort of on the todo list
>> that we never quite sorted out. Does the kernel have the API in
>> it to query the offset these days?
>> 
>> -- PMM
>> 
>
> Marc has a patch, I checked 3.18.0-rc2 it's not in yet.
>
> Marc is this a patch you're planing to upstream in near
> future?

The problem is slightly more complicated than it did look initially:

It is expected that the GICV physical address straddles two 64k pages,
so that GICV_DIR can be trapped independently from the rest of the GICV
accesses, irrespective of the page size. For this reason, we often
end-up with GICV being at an address looking like 0xbcdef000, and
aliases of the first part of GICV all the way in
[0xbcde0000-0xbcdee000], and the second half aliased in
[0xbcdf0000-0xbcdff000].

It appears that a number of platforms have other things sitting in the
range [0xbcde0000-0xbcdeffff], and with 64k pages there is no way we can
prevent the guest from accessing this.

Other platforms have an equally braindead mapping, with the first 4k of
GICV is *only* at 0xbcde0000 and the second one *only* at 0xbcdf0000 (in
violation of the GIC architecture spec).

So we need two things to happen:
- an extension of the DT bindings describing the actual GICV
  layout. Something like:

        reg = <...>,                // Other GIC regs
              <0xbcde0000 0x20000>; // GICV
        gicv-ctlr-offset = <0xf000>;
        gicv-dir-offset = <0x10000>;


- A userspace API similar to my earlier patch, reporting the various
  offsets.

In all cases, each individual platform needs to be investigated to find
out if they are sane or not (platforms having another device than the
GIC in the same 64k page will never be supported with 64k pages).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm




[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux