Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Mario Smarduch <m.smarduch@samsung.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Christopher Covington <cov@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, linux@arm.linux.org.uk,
	andre.przywara@arm.com, grant.likely@secretlab.ca,
	robherring2@gmail.com, christoffer.dall@linaro.org,
	marc.zyngier@arm.com, 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 11:17:12 -0800	[thread overview]
Message-ID: <56390838.3000204@samsung.com> (raw)
In-Reply-To: <20151103175522.GA24856@arm.com>



On 11/3/2015 9:55 AM, Will Deacon wrote:
> On Tue, Nov 03, 2015 at 09:44:52AM -0800, Mario Smarduch wrote:
>> On 11/3/2015 8:33 AM, Christopher Covington wrote:
>>> On 11/02/2015 06:51 PM, Mario Smarduch wrote:
>>>>    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?
> 
> We make absolutely no guarantees about the memory map provided by kvmtool.
> 
> Will
> 

If that's also the case for qemu, then I guess the best you can do is find a way
to dump the device tree. Find the uart, physical address and try figure out the
virtual address.

Pretty involved, hoped for something more automated since that's a handy feature.

Thanks,
- Mario.

  reply	other threads:[~2015-11-03 19:17 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
2015-11-03 17:55     ` Will Deacon
2015-11-03 19:17       ` Mario Smarduch [this message]
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=56390838.3000204@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