Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Mario Smarduch <m.smarduch@samsung.com>
To: Christopher Covington <cov@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux@arm.linux.org.uk,
	will.deacon@arm.com, andre.przywara@arm.com,
	grant.likely@secretlab.ca, robherring2@gmail.com,
	christoffer.dall@linaro.org, marc.zyngier@arm.com
Cc: catalin.marinas@arm.com, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
Date: Tue, 03 Nov 2015 09:44:52 -0800	[thread overview]
Message-ID: <5638F294.4060409@samsung.com> (raw)
In-Reply-To: <5638E1CD.8090006@codeaurora.org>



On 11/3/2015 8:33 AM, Christopher Covington wrote:
> Hi Mario,
> 
> On 11/02/2015 06:51 PM, Mario Smarduch wrote:
>> Hello,
>>    this is a re-post from couple weeks ago, please take time to review this 
>> simple patch which simplifies DEBUG_LL and prevents kernel crash on virtual 
>> platforms.
>>
>> Before this patch DEBUG_LL for 'dummy virtual machine':
>>
>> ( ) Kernel low-level debugging via EmbeddedICE DCC channel
>> ( ) Kernel low-level debug output via semihosting I/O
>> ( ) Kernel low-level debugging via 8250 UART
>> ( ) Kernel low-level debugging via ARM Ltd PL01x Primecell
>>
>> In summary if debug uart is not emulated kernel crashes.
>> And once you pass that hurdle, uart physical/virtual addresses are unknown.
>> DEBUG_LL comes in handy on many occasions and should be somewhat 
>> intuitive to use like it is for physical platforms. For virtual platforms
>> user may start daubting the host and get into a bigger mess.
>>
>> After this patch is applied user gets:
>>
>> (X) Kernel low-level debugging on QEMU Virtual Platform
>> ( ) Kernel low-level debugging on Kvmtool Virtual Platform
>> 	..... above repeated ....
>>
>> The virtual addresses selected follow arm reference models, high in vmalloc 
>> section with high mem enabled and guest running with >= 1GB of memory. The 
>> offset is leftover from arm reference models.
> 
> Which model? It doesn't appear to match the vexpress AEM/RTSM/FVP/whatever
> which used 0x1c090000 for UART0.

I recall QEMU virt model had it's own physical address map, for sure I saw the
virtio-mmio regions assigned in some ARM document. Peter would you know?

As far as kvmtool I'm not sure, currently PC1 COM1 port is used? Andre will that
stay fixed?

> 
>> The patch is against 4.2.0-rc2 commit 43297dda0a51
>>
>> Original Description
>> --------------------
>> When booting a VM using QEMU or Kvmtool there are no clear ways to 
>> enable low level debugging for these virtual platforms. some menu port 
>> choices are not supported by the virtual platforms at all. And there is no
>> help on the location of physical and virtual addresses for the ports.
>> This may lead to wrong debug port and a frozen VM with a blank screen.
>>
>> This patch adds menu selections for QEMU and Kvmtool virtual platforms for low 
>> level kernel print debugging. Help section displays port physical and
>> virutal addresses.
>>
>> ARM reference models use the MIDR register to run-time select UART port address 
>> (for ARCH_VEXPRESS) based on A9 or A15 part numbers. Looked for a same approach
>> but couldn't find a way to differentiate between virtual platforms, something
>> like a platform register.
>>
>> Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
>> Signed-off-by: Mario Smarduch <m.smarduch@samsung.com>
>> ---
>>  arch/arm/Kconfig.debug | 22 ++++++++++++++++++++++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index a2e16f9..d126bd4 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -1155,6 +1155,28 @@ choice
>>  		  This option selects UART0 on VIA/Wondermedia System-on-a-chip
>>  		  devices, including VT8500, WM8505, WM8650 and WM8850.
>>  
>> +	config DEBUG_VIRT_UART_QEMU
>> +		bool "Kernel low-level debugging on QEMU Virtual Platform"
>> +		depends on ARCH_VIRT
>> +		select DEBUG_UART_PL01X
>> +		help
>> +		  Say Y here if you want the debug print routines to direct
>> +		  their output to PL011 UART port on QEMU Virtual Platform.
>> +		  Appropriate address values are:
>> +			PHYS		VIRT
>> +			0x9000000	0xf8090000
> 
> I thought the only guarantee the virt machine had about the memory map was
> that it would be described in the device tree.
> 
>> +	config DEBUG_VIRT_UART_KVMTOOL
>> +		bool "Kernel low-level debugging on Kvmtool Virtual Platform"
>> +		depends on ARCH_VIRT
>> +		select DEBUG_UART_8250
>> +		help
>> +		  Say Y here if you want the debug print routines to direct
>> +		  their output to 8250 UART port on Kvmtool Virtual
>> +		  Platform. Appropriate address values are:
>> +			PHYS		VIRT
>> +			0x3f8		0xf80903f8
>> +
>>  	config DEBUG_ICEDCC
>>  		bool "Kernel low-level debugging via EmbeddedICE DCC channel"
>>  		help
>>
> 
> Regards,
> Christopher Covington
> 

  parent reply	other threads:[~2015-11-03 17:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02 23:51 [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms Mario Smarduch
2015-11-03 16:33 ` Christopher Covington
2015-11-03 17:33   ` Russell King - ARM Linux
2015-11-03 17:44   ` Mario Smarduch [this message]
2015-11-03 17:55     ` Will Deacon
2015-11-03 19:17       ` Mario Smarduch
2015-11-03 19:39         ` Rob Herring
2015-11-04 13:31           ` Christoffer Dall
2015-11-04 18:49             ` Christopher Covington
2015-11-04 18:51               ` Ard Biesheuvel
2015-11-04 23:28                 ` Mario Smarduch
2015-11-05  1:13                   ` Peter Hurley
2015-11-05 15:04                 ` Christoffer Dall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5638F294.4060409@samsung.com \
    --to=m.smarduch@samsung.com \
    --cc=andre.przywara@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=cov@codeaurora.org \
    --cc=grant.likely@secretlab.ca \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=robherring2@gmail.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox