From: Will Deacon <will.deacon@arm.com>
To: Mario Smarduch <m.smarduch@samsung.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, 3 Nov 2015 17:55:23 +0000 [thread overview]
Message-ID: <20151103175522.GA24856@arm.com> (raw)
In-Reply-To: <5638F294.4060409@samsung.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
Date: Tue, 3 Nov 2015 17:55:23 +0000 [thread overview]
Message-ID: <20151103175522.GA24856@arm.com> (raw)
In-Reply-To: <5638F294.4060409@samsung.com>
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
next prev parent reply other threads:[~2015-11-03 17:55 UTC|newest]
Thread overview: 26+ 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-02 23:51 ` Mario Smarduch
2015-11-03 16:33 ` Christopher Covington
2015-11-03 16:33 ` Christopher Covington
2015-11-03 17:33 ` Russell King - ARM Linux
2015-11-03 17:33 ` Russell King - ARM Linux
2015-11-03 17:44 ` Mario Smarduch
2015-11-03 17:44 ` Mario Smarduch
2015-11-03 17:55 ` Will Deacon [this message]
2015-11-03 17:55 ` Will Deacon
2015-11-03 19:17 ` Mario Smarduch
2015-11-03 19:17 ` Mario Smarduch
2015-11-03 19:39 ` Rob Herring
2015-11-03 19:39 ` Rob Herring
2015-11-04 13:31 ` Christoffer Dall
2015-11-04 13:31 ` Christoffer Dall
2015-11-04 18:49 ` Christopher Covington
2015-11-04 18:49 ` Christopher Covington
2015-11-04 18:51 ` Ard Biesheuvel
2015-11-04 18:51 ` Ard Biesheuvel
2015-11-04 23:28 ` Mario Smarduch
2015-11-04 23:28 ` Mario Smarduch
2015-11-05 1:13 ` Peter Hurley
2015-11-05 1:13 ` Peter Hurley
2015-11-05 15:04 ` Christoffer Dall
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=20151103175522.GA24856@arm.com \
--to=will.deacon@arm.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=m.smarduch@samsung.com \
--cc=marc.zyngier@arm.com \
--cc=robherring2@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.