Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
On Wed, Nov 04, 2015 at 07:51:58PM +0100, Ard Biesheuvel wrote: > On 4 November 2015 at 19:49, Christopher Covington> wrote: > > On 11/04/2015 08:31 AM, Christoffer Dall wrote: > >> On Tue, Nov 03, 2015 at 01:39:44PM -0600, Rob Herring wrote: > >>> On Tue, Nov 3, 2015 at 1:17 PM, Mario Smarduch > >>> wrote: > 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 0x1c09 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. > > 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. > >>> > >>> You really only need LL_DEBUG now if you are debugging very early code > >>> before memory is setup and/or bad memory. Use earlycon instead which > >>> should already be supported both via the pl011 or semihosting. I used > >>> it with QEMU semihosting support. > >>> > >> Then we should really document how to use that with qemu's virt platform > >> and kvmtool's platform on both 32-bit and 64-bit so that users can > >> easily figure out what they're doing wrong when they get no output. > >> > >> In practice, the address for the pl011 is quite unlikely to change, I > >> dare speculate, so that documentation shouldn't need frequent updating. > > > > Is it not on by default since the following change? > > > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f022b8e95379b0433d13509706b66f38fc15dde8 > > > > Yes, but it still requires the plain 'earlycon' argument (i.e, without > '=pl011,...') to be passed on the kernel command line if you want > early output. > I didn't notice this. Cool! -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
On 11/4/2015 10:51 AM, Ard Biesheuvel wrote: > On 4 November 2015 at 19:49, Christopher Covington> wrote: >> On 11/04/2015 08:31 AM, Christoffer Dall wrote: >>> On Tue, Nov 03, 2015 at 01:39:44PM -0600, Rob Herring wrote: On Tue, Nov 3, 2015 at 1:17 PM, Mario Smarduch wrote: > 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 0x1c09 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. > > 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. You really only need LL_DEBUG now if you are debugging very early code before memory is setup and/or bad memory. Use earlycon instead which should already be supported both via the pl011 or semihosting. I used it with QEMU semihosting support. >>> Then we should really document how to use that with qemu's virt platform >>> and kvmtool's platform on both 32-bit and 64-bit so that users can >>> easily figure out what they're doing wrong when they get no output. >>> >>> In practice, the address for the pl011 is quite unlikely to change, I >>> dare speculate, so that documentation shouldn't need frequent updating. >> >> Is it not on by default since the following change? >> >> http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f022b8e95379b0433d13509706b66f38fc15dde8 >> > > Yes, but it still requires the plain 'earlycon' argument (i.e, without > '=pl011,...') to be passed on the kernel command line if you want > early output. > I spent time debugging 'earlycon' for pl011, ironically using DEBUG_LL, from the looks of it no mmio uart should work for armv7. It appears earlycon_map() requires a fixed mapping similar to arm64. Comparing both options, DEBUG_LL takes you from kernel decompress code to early FDT parsing. A lot of early_print() calls won't work if DEBUG_LL is not enabled including dump_machine_table which ends in a endless loop. IMO it's worth turning this option on for that and other reasons. 'earlycon' is enabled some ways up in setup_arch(). As far as the patch, providing a hint to the user with probable uart addresses would help and in the worst case "see the latest device tree for the virtual platform". - Mario -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
On 11/04/2015 06:28 PM, Mario Smarduch wrote: > I spent time debugging 'earlycon' for pl011, ironically using DEBUG_LL, from > the > looks of it no mmio uart should work for armv7. It appears earlycon_map() > requires a fixed mapping similar to arm64. commit a5f4c561b3b1 ("ARM: 8415/1: early fixmap support for earlycon") added ARM fixmap support for earlycon since 4.3-rc1. That was in it's 5th revision; various versions have been on lkml since Dec 2014 or so. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
On Tue, Nov 03, 2015 at 01:39:44PM -0600, Rob Herring wrote: > On Tue, Nov 3, 2015 at 1:17 PM, Mario Smarduchwrote: > > > > > > 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 0x1c09 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. > > You really only need LL_DEBUG now if you are debugging very early code > before memory is setup and/or bad memory. Use earlycon instead which > should already be supported both via the pl011 or semihosting. I used > it with QEMU semihosting support. > Then we should really document how to use that with qemu's virt platform and kvmtool's platform on both 32-bit and 64-bit so that users can easily figure out what they're doing wrong when they get no output. In practice, the address for the pl011 is quite unlikely to change, I dare speculate, so that documentation shouldn't need frequent updating. -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
On 11/04/2015 08:31 AM, Christoffer Dall wrote: > On Tue, Nov 03, 2015 at 01:39:44PM -0600, Rob Herring wrote: >> On Tue, Nov 3, 2015 at 1:17 PM, Mario Smarduch>> wrote: >>> 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 0x1c09 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. >>> >>> 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. >> >> You really only need LL_DEBUG now if you are debugging very early code >> before memory is setup and/or bad memory. Use earlycon instead which >> should already be supported both via the pl011 or semihosting. I used >> it with QEMU semihosting support. >> > Then we should really document how to use that with qemu's virt platform > and kvmtool's platform on both 32-bit and 64-bit so that users can > easily figure out what they're doing wrong when they get no output. > > In practice, the address for the pl011 is quite unlikely to change, I > dare speculate, so that documentation shouldn't need frequent updating. Is it not on by default since the following change? http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f022b8e95379b0433d13509706b66f38fc15dde8 Christopher Covington -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
On 4 November 2015 at 19:49, Christopher Covingtonwrote: > On 11/04/2015 08:31 AM, Christoffer Dall wrote: >> On Tue, Nov 03, 2015 at 01:39:44PM -0600, Rob Herring wrote: >>> On Tue, Nov 3, 2015 at 1:17 PM, Mario Smarduch >>> wrote: 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 0x1c09 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. 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. >>> >>> You really only need LL_DEBUG now if you are debugging very early code >>> before memory is setup and/or bad memory. Use earlycon instead which >>> should already be supported both via the pl011 or semihosting. I used >>> it with QEMU semihosting support. >>> >> Then we should really document how to use that with qemu's virt platform >> and kvmtool's platform on both 32-bit and 64-bit so that users can >> easily figure out what they're doing wrong when they get no output. >> >> In practice, the address for the pl011 is quite unlikely to change, I >> dare speculate, so that documentation shouldn't need frequent updating. > > Is it not on by default since the following change? > > http://git.qemu.org/?p=qemu.git;a=commitdiff;h=f022b8e95379b0433d13509706b66f38fc15dde8 > Yes, but it still requires the plain 'earlycon' argument (i.e, without '=pl011,...') to be passed on the kernel command line if you want early output. -- Ard. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
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 0x1c09 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>> Signed-off-by: Mario Smarduch >> --- >> 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: >> +PHYSVIRT >> +0x900 0xf809 > > 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: >> +PHYSVIRT >> +0x3f8 0xf80903f8 >> + >> config DEBUG_ICEDCC >> bool "Kernel low-level debugging via EmbeddedICE DCC channel" >> help >> > > Regards, > Christopher Covington > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
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 0x1c09 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
On Tue, Nov 3, 2015 at 1:17 PM, Mario Smarduchwrote: > > > 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 0x1c09 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. You really only need LL_DEBUG now if you are debugging very early code before memory is setup and/or bad memory. Use earlycon instead which should already be supported both via the pl011 or semihosting. I used it with QEMU semihosting support. Rob -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
On Tue, Nov 03, 2015 at 11:33:17AM -0500, Christopher Covington wrote: > > 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: > > + PHYSVIRT > > + 0x900 0xf809 > > I thought the only guarantee the virt machine had about the memory map was > that it would be described in the device tree. This LL debug stuff is used prior to device tree being parsed. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
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 0x1c09 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM/arm: kernel low level debug support for ARM32 virtual platforms
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 0x1c09 for UART0. > 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> Signed-off-by: Mario Smarduch > --- > 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: > + PHYSVIRT > + 0x900 0xf809 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: > + PHYSVIRT > + 0x3f8 0xf80903f8 > + > config DEBUG_ICEDCC > bool "Kernel low-level debugging via EmbeddedICE DCC channel" > help > Regards, Christopher Covington -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html