linux-kernel - Re: [PATCH 0/9] arm64: dts: rockchip: Initial Toybrick TB-RK1808M0 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87im3hvikv.wl-maz@kernel.org>
Date:   Mon, 17 May 2021 10:02:40 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Andreas Färber <afaerber@...e.de>
Cc:     linux-rockchip@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH 0/9] arm64: dts: rockchip: Initial Toybrick TB-RK1808M0 support

On Mon, 17 May 2021 00:05:42 +0100,
Andreas Färber <afaerber@...e.de> wrote:
> 
> Hello Heiko et al.,
> 
> It seems linux-rockchip list only saw two RK1808 patches for ASoC in 2019.
> Following up on a SUSE Hackweek 20 project of mine, here's some patches that
> allow me to start booting into the TB-RK1808M0 mPCIe card's eMMC.
> 
> Tested using its USB adapter, which allows to connect a serial cable and a
> USB storage device that I load kernel+dtb from. It has a reset button, and
> Ctrl+C allows to enter a U-Boot prompt (without EBBR/UEFI support though).
> 
> Patches are based on the shipping toybrick.dtb file.
> http://t.rock-chips.com/en/wiki.php?mod=view&id=110 gives instructions for
> compiling sources, but no source download or link is actually provided.
> 
> I encountered a hang: earlycon revealed it being related to KVM and
> vGIC.  Disabling KVM in Kconfig works around it, as does removing
> the vGIC irq in DT.  I've already tried low and high for the vGIC
> interrupt, so no clue what might cause it. On an mPCIe card with 1
> GiB of RAM I figured KVM is not going to be a major use case, so if
> we find no other solution, we could just delete the interrupts
> property in its .dts, as demonstrated here.

I think you figured it out wrong, for a number of reasons:

- KVM hanging is usually a sign that you have described the platform
  the wrong way. Either you are stepping over reserved memory regions,
  or you have badly described the GIC itself.

- It could also be a bug in KVM, which will need to be fixed. If
  that's because the HW is broken, we need to be able to detect it.

- You cannot be prescriptive of what a user is going to run. People
  have been running KVM on systems with less memory than that.

So no, we don't paper over these issues. We work out what is going
wrong and we fix it.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.