qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
@ 2014-08-07 10:42 Richard W.M. Jones
  2014-08-07 11:18 ` Peter Maydell
  0 siblings, 1 reply; 12+ messages in thread
From: Richard W.M. Jones @ 2014-08-07 10:42 UTC (permalink / raw)
  To: qemu-devel

(gdb) set architecture aarch64
The target architecture is assumed to be aarch64
(gdb) target remote tcp::1234
Remote debugging using tcp::1234
warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
warning: Could not load XML target description; ignoring

Note that I've set the architecture to `aarch64', so it looks as if
gdb is requesting and/or qemu is sending the wrong name of the XML
file.

Also `info registers' is broken, but that's probably just a
consequence of the warnings.

(gdb) info registers 
x0             0x0   0
x1             0x0   0
x2             0x0   0
x3             0x0   0
x4             0x0   0
x5             0x0   0
x6             0x0   0
x7             0x4000000000000000	4611686018427387904
x8             0x7f400001d3		546534588883
x9             0x0			0
x10            0x0			0
x11            0x0			0
x12            0x0			0
x13            0x0			0
x14            0x0			0
x15            0x40000000		1073741824
Could not fetch register "x16"; remote failure reply 'E14'

Versions:

qemu from git today
GNU gdb (GDB) Fedora 7.8-15.fc22
kernel 3.16.0

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 10:42 [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml" Richard W.M. Jones
@ 2014-08-07 11:18 ` Peter Maydell
  2014-08-07 11:29   ` Richard W.M. Jones
  0 siblings, 1 reply; 12+ messages in thread
From: Peter Maydell @ 2014-08-07 11:18 UTC (permalink / raw)
  To: Richard W.M. Jones; +Cc: QEMU Developers

On 7 August 2014 11:42, Richard W.M. Jones <rjones@redhat.com> wrote:
> (gdb) set architecture aarch64
> The target architecture is assumed to be aarch64
> (gdb) target remote tcp::1234
> Remote debugging using tcp::1234
> warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
> warning: Could not load XML target description; ignoring
>
> Note that I've set the architecture to `aarch64', so it looks as if
> gdb is requesting and/or qemu is sending the wrong name of the XML
> file.

Works for me:

e104462:trusty:linux-clean$ gdb-multiarch
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) set arch aarch64
The target architecture is assumed to be aarch64
(gdb) target remote :1234
Remote debugging using :1234
0x0000000040000000 in ?? ()
(gdb)

We only send arm-core.xml for 32 bit CPUs: are you sure
you didn't select a 32 bit CPU either explicitly or by default
on the QEMU command line? Note that '-machine type=virt'
defaults to a Cortex-A15 even in qemu-softmmu-aarch64
(this is unfortunate but fallout from the fact that we started
the virt model with the A15. Maybe we should make it not
have a default and require a CPU specification...)

thanks
-- PMM

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 11:18 ` Peter Maydell
@ 2014-08-07 11:29   ` Richard W.M. Jones
  2014-08-07 11:35     ` Peter Maydell
  0 siblings, 1 reply; 12+ messages in thread
From: Richard W.M. Jones @ 2014-08-07 11:29 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

On Thu, Aug 07, 2014 at 12:18:49PM +0100, Peter Maydell wrote:
> you didn't select a 32 bit CPU either explicitly or by default
> on the QEMU command line? Note that '-machine type=virt'
> defaults to a Cortex-A15 even in qemu-softmmu-aarch64
> (this is unfortunate but fallout from the fact that we started
> the virt model with the A15. Maybe we should make it not
> have a default and require a CPU specification...)

Yes, this is indeed the case.  It also explains why I could get TCG
working at all until I added -cpu cortex-a57.  Now it is working.

I really think this choice of cpu_model = "cortex-a15" for -M virt is
a poor one.  It should always default to something working.

Currently libguestfs has to pass -cpu host when KVM is detected, and
-cpu cortex-a57 otherwise.  However we cannot be sure that KVM is 100%
working and that we won't fall back to TCG, which means the -cpu
parameter could be wrong and we would fail to launch the appliance.
Having the correct defaults would prevent this unnecessary failure.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 11:29   ` Richard W.M. Jones
@ 2014-08-07 11:35     ` Peter Maydell
  2014-08-07 11:43       ` Richard W.M. Jones
  0 siblings, 1 reply; 12+ messages in thread
From: Peter Maydell @ 2014-08-07 11:35 UTC (permalink / raw)
  To: Richard W.M. Jones; +Cc: QEMU Developers

On 7 August 2014 12:29, Richard W.M. Jones <rjones@redhat.com> wrote:
> On Thu, Aug 07, 2014 at 12:18:49PM +0100, Peter Maydell wrote:
>> you didn't select a 32 bit CPU either explicitly or by default
>> on the QEMU command line? Note that '-machine type=virt'
>> defaults to a Cortex-A15 even in qemu-softmmu-aarch64
>> (this is unfortunate but fallout from the fact that we started
>> the virt model with the A15. Maybe we should make it not
>> have a default and require a CPU specification...)
>
> Yes, this is indeed the case.  It also explains why I could get TCG
> working at all until I added -cpu cortex-a57.  Now it is working.
>
> I really think this choice of cpu_model = "cortex-a15" for -M virt is
> a poor one.  It should always default to something working.

cortex-a15 *does* work, it's just a 32 bit CPU. It will function
exactly the same as if you asked for an A15 in qemu-system-arm.
Obviously if you try to feed it an AArch64 kernel it will behave
the same way as if you'd tried to boot an AArch64 kernel on
A15 hardware, so don't do that.

> Currently libguestfs has to pass -cpu host when KVM is detected, and
> -cpu cortex-a57 otherwise.  However we cannot be sure that KVM is 100%
> working and that we won't fall back to TCG, which means the -cpu
> parameter could be wrong and we would fail to launch the appliance.
> Having the correct defaults would prevent this unnecessary failure.

This isn't possible, I'm afraid. TCG will never support "-cpu host",
and whether any particular specific CPU type is supported by
the kernel for KVM depends on the host hardware. (We don't
want to default to "-cpu host if KVM" because it means defaulting
to "migration won't work".)

thanks
-- PMM

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 11:35     ` Peter Maydell
@ 2014-08-07 11:43       ` Richard W.M. Jones
  2014-08-07 12:03         ` Peter Maydell
  0 siblings, 1 reply; 12+ messages in thread
From: Richard W.M. Jones @ 2014-08-07 11:43 UTC (permalink / raw)
  To: Peter Maydell; +Cc: QEMU Developers

On Thu, Aug 07, 2014 at 12:35:27PM +0100, Peter Maydell wrote:
> On 7 August 2014 12:29, Richard W.M. Jones <rjones@redhat.com> wrote:
> > On Thu, Aug 07, 2014 at 12:18:49PM +0100, Peter Maydell wrote:
> >> you didn't select a 32 bit CPU either explicitly or by default
> >> on the QEMU command line? Note that '-machine type=virt'
> >> defaults to a Cortex-A15 even in qemu-softmmu-aarch64
> >> (this is unfortunate but fallout from the fact that we started
> >> the virt model with the A15. Maybe we should make it not
> >> have a default and require a CPU specification...)
> >
> > Yes, this is indeed the case.  It also explains why I could get TCG
> > working at all until I added -cpu cortex-a57.  Now it is working.
> >
> > I really think this choice of cpu_model = "cortex-a15" for -M virt is
> > a poor one.  It should always default to something working.
> 
> cortex-a15 *does* work, it's just a 32 bit CPU. It will function
> exactly the same as if you asked for an A15 in qemu-system-arm.
> Obviously if you try to feed it an AArch64 kernel it will behave
> the same way as if you'd tried to boot an AArch64 kernel on
> A15 hardware, so don't do that.

Can't a 32 bit kernel run on -cpu cortex-a5x?  (I've not tried.)

> > Currently libguestfs has to pass -cpu host when KVM is detected, and
> > -cpu cortex-a57 otherwise.  However we cannot be sure that KVM is 100%
> > working and that we won't fall back to TCG, which means the -cpu
> > parameter could be wrong and we would fail to launch the appliance.
> > Having the correct defaults would prevent this unnecessary failure.
> 
> This isn't possible, I'm afraid. TCG will never support "-cpu host",
> and whether any particular specific CPU type is supported by
> the kernel for KVM depends on the host hardware. (We don't
> want to default to "-cpu host if KVM" because it means defaulting
> to "migration won't work".)

We use -cpu host on KVM in order to avoid parsing /proc/cpuinfo to
find the right CPU model and flags.  Parsing /proc/cpuinfo is a
minefield because it differs on every architecture, and even within
architectures.

Note libguestfs doesn't care about migration at all.  We do care that
we can reliably run our appliance.

What we really want is -cpu best-possible-and-don't-fail.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 11:43       ` Richard W.M. Jones
@ 2014-08-07 12:03         ` Peter Maydell
  2014-08-07 13:43           ` Christopher Covington
  0 siblings, 1 reply; 12+ messages in thread
From: Peter Maydell @ 2014-08-07 12:03 UTC (permalink / raw)
  To: Richard W.M. Jones; +Cc: QEMU Developers

On 7 August 2014 12:43, Richard W.M. Jones <rjones@redhat.com> wrote:
> On Thu, Aug 07, 2014 at 12:35:27PM +0100, Peter Maydell wrote:
>> On 7 August 2014 12:29, Richard W.M. Jones <rjones@redhat.com> wrote:
>> > On Thu, Aug 07, 2014 at 12:18:49PM +0100, Peter Maydell wrote:
>> >> you didn't select a 32 bit CPU either explicitly or by default
>> >> on the QEMU command line? Note that '-machine type=virt'
>> >> defaults to a Cortex-A15 even in qemu-softmmu-aarch64
>> >> (this is unfortunate but fallout from the fact that we started
>> >> the virt model with the A15. Maybe we should make it not
>> >> have a default and require a CPU specification...)
>> >
>> > Yes, this is indeed the case.  It also explains why I could get TCG
>> > working at all until I added -cpu cortex-a57.  Now it is working.
>> >
>> > I really think this choice of cpu_model = "cortex-a15" for -M virt is
>> > a poor one.  It should always default to something working.
>>
>> cortex-a15 *does* work, it's just a 32 bit CPU. It will function
>> exactly the same as if you asked for an A15 in qemu-system-arm.
>> Obviously if you try to feed it an AArch64 kernel it will behave
>> the same way as if you'd tried to boot an AArch64 kernel on
>> A15 hardware, so don't do that.
>
> Can't a 32 bit kernel run on -cpu cortex-a5x?  (I've not tried.)

No, because at the moment our AArch64 TCG implementation
(and the way we configure KVM) assumes that the highest
exception level is running AArch64. We might fix this eventually,
though.

>> > Currently libguestfs has to pass -cpu host when KVM is detected, and
>> > -cpu cortex-a57 otherwise.  However we cannot be sure that KVM is 100%
>> > working and that we won't fall back to TCG, which means the -cpu
>> > parameter could be wrong and we would fail to launch the appliance.
>> > Having the correct defaults would prevent this unnecessary failure.
>>
>> This isn't possible, I'm afraid. TCG will never support "-cpu host",
>> and whether any particular specific CPU type is supported by
>> the kernel for KVM depends on the host hardware. (We don't
>> want to default to "-cpu host if KVM" because it means defaulting
>> to "migration won't work".)
>
> We use -cpu host on KVM in order to avoid parsing /proc/cpuinfo to
> find the right CPU model and flags.  Parsing /proc/cpuinfo is a
> minefield because it differs on every architecture, and even within
> architectures.
>
> Note libguestfs doesn't care about migration at all.  We do care that
> we can reliably run our appliance.

Yes, so -cpu host is a good choice for you. It's just not something
I want to make the default in QEMU itself, where we have more
than just the libguestfs use case to consider.

> What we really want is -cpu best-possible-and-don't-fail.

The difficulty here is that there is no good definition of
"best" because ARM CPUs come from a variety of different
manufacturers and with various different possible configurations.
Also, even if we could define a "best" CPU, it's quite possible
that your guest kernel wouldn't run on it (either now or in the
future when new CPUs get added).

thanks
-- PMM

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 12:03         ` Peter Maydell
@ 2014-08-07 13:43           ` Christopher Covington
  2014-08-07 13:53             ` Peter Maydell
  0 siblings, 1 reply; 12+ messages in thread
From: Christopher Covington @ 2014-08-07 13:43 UTC (permalink / raw)
  To: Peter Maydell; +Cc: Richard W.M. Jones, QEMU Developers

On 08/07/2014 08:03 AM, Peter Maydell wrote:
> On 7 August 2014 12:43, Richard W.M. Jones <rjones@redhat.com> wrote:
>> On Thu, Aug 07, 2014 at 12:35:27PM +0100, Peter Maydell wrote:
>>> On 7 August 2014 12:29, Richard W.M. Jones <rjones@redhat.com> wrote:
>>>> On Thu, Aug 07, 2014 at 12:18:49PM +0100, Peter Maydell wrote:
>>>>> you didn't select a 32 bit CPU either explicitly or by default
>>>>> on the QEMU command line? Note that '-machine type=virt'
>>>>> defaults to a Cortex-A15 even in qemu-softmmu-aarch64
>>>>> (this is unfortunate but fallout from the fact that we started
>>>>> the virt model with the A15. Maybe we should make it not
>>>>> have a default and require a CPU specification...)
>>>>
>>>> Yes, this is indeed the case.  It also explains why I could get TCG
>>>> working at all until I added -cpu cortex-a57.  Now it is working.
>>>>
>>>> I really think this choice of cpu_model = "cortex-a15" for -M virt is
>>>> a poor one.  It should always default to something working.
>>>
>>> cortex-a15 *does* work, it's just a 32 bit CPU. It will function
>>> exactly the same as if you asked for an A15 in qemu-system-arm.
>>> Obviously if you try to feed it an AArch64 kernel it will behave
>>> the same way as if you'd tried to boot an AArch64 kernel on
>>> A15 hardware, so don't do that.
>>
>> Can't a 32 bit kernel run on -cpu cortex-a5x?  (I've not tried.)
> 
> No, because at the moment our AArch64 TCG implementation
> (and the way we configure KVM) assumes that the highest
> exception level is running AArch64. We might fix this eventually,
> though.

When EL3 and EL2 support is added, the bootloader will presumably have to be
modified to make the switch from EL3 into EL2. In my experience switching into
AArch32 EL2 instead of AArch64 EL2 is an easy option to add.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 13:43           ` Christopher Covington
@ 2014-08-07 13:53             ` Peter Maydell
  2014-08-07 14:13               ` Christopher Covington
  2014-08-07 15:06               ` Richard W.M. Jones
  0 siblings, 2 replies; 12+ messages in thread
From: Peter Maydell @ 2014-08-07 13:53 UTC (permalink / raw)
  To: Christopher Covington; +Cc: Richard W.M. Jones, QEMU Developers

On 7 August 2014 14:43, Christopher Covington <cov@codeaurora.org> wrote:
> On 08/07/2014 08:03 AM, Peter Maydell wrote:
>> No, because at the moment our AArch64 TCG implementation
>> (and the way we configure KVM) assumes that the highest
>> exception level is running AArch64. We might fix this eventually,
>> though.
>
> When EL3 and EL2 support is added, the bootloader will
> presumably have to be modified to make the switch from
> EL3 into EL2. In my experience switching into AArch32
> EL2 instead of AArch64 EL2 is an easy option to add.

I think the biggest difficulty is not the code to actually
do the switch but figuring out what the command line
UI to request "start in AArch32" ought to be and how that
then gets plumbed into the code to do the actual work.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 13:53             ` Peter Maydell
@ 2014-08-07 14:13               ` Christopher Covington
  2014-08-07 14:53                 ` Peter Maydell
  2014-08-07 15:06               ` Richard W.M. Jones
  1 sibling, 1 reply; 12+ messages in thread
From: Christopher Covington @ 2014-08-07 14:13 UTC (permalink / raw)
  To: Peter Maydell; +Cc: Richard W.M. Jones, QEMU Developers

On 08/07/2014 09:53 AM, Peter Maydell wrote:
> On 7 August 2014 14:43, Christopher Covington <cov@codeaurora.org> wrote:
>> On 08/07/2014 08:03 AM, Peter Maydell wrote:
>>> No, because at the moment our AArch64 TCG implementation
>>> (and the way we configure KVM) assumes that the highest
>>> exception level is running AArch64. We might fix this eventually,
>>> though.
>>
>> When EL3 and EL2 support is added, the bootloader will
>> presumably have to be modified to make the switch from
>> EL3 into EL2. In my experience switching into AArch32
>> EL2 instead of AArch64 EL2 is an easy option to add.
> 
> I think the biggest difficulty is not the code to actually
> do the switch but figuring out what the command line
> UI to request "start in AArch32" ought to be and how that
> then gets plumbed into the code to do the actual work.

ELF-32 file passed to -kernel seems to me like a reasonable place to start.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 14:13               ` Christopher Covington
@ 2014-08-07 14:53                 ` Peter Maydell
  0 siblings, 0 replies; 12+ messages in thread
From: Peter Maydell @ 2014-08-07 14:53 UTC (permalink / raw)
  To: Christopher Covington; +Cc: Richard W.M. Jones, QEMU Developers

On 7 August 2014 15:13, Christopher Covington <cov@codeaurora.org> wrote:
> On 08/07/2014 09:53 AM, Peter Maydell wrote:
>> I think the biggest difficulty is not the code to actually
>> do the switch but figuring out what the command line
>> UI to request "start in AArch32" ought to be and how that
>> then gets plumbed into the code to do the actual work.
>
> ELF-32 file passed to -kernel seems to me like a reasonable place to start.

The semantics of "-kernel got a 32-bit ELF file" are "this is
not a Linux kernel image at all", so that won't work. In general
kernels aren't ELF files (either for AArch32 or AArch64).

(Also, what if you want to start your guest via UEFI bios
blob and having it load the kernel off a disk image?)

thanks
-- PMM

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 13:53             ` Peter Maydell
  2014-08-07 14:13               ` Christopher Covington
@ 2014-08-07 15:06               ` Richard W.M. Jones
  2014-08-07 15:39                 ` Peter Maydell
  1 sibling, 1 reply; 12+ messages in thread
From: Richard W.M. Jones @ 2014-08-07 15:06 UTC (permalink / raw)
  To: Peter Maydell; +Cc: Christopher Covington, QEMU Developers

On Thu, Aug 07, 2014 at 02:53:33PM +0100, Peter Maydell wrote:
> On 7 August 2014 14:43, Christopher Covington <cov@codeaurora.org> wrote:
> > On 08/07/2014 08:03 AM, Peter Maydell wrote:
> >> No, because at the moment our AArch64 TCG implementation
> >> (and the way we configure KVM) assumes that the highest
> >> exception level is running AArch64. We might fix this eventually,
> >> though.
> >
> > When EL3 and EL2 support is added, the bootloader will
> > presumably have to be modified to make the switch from
> > EL3 into EL2. In my experience switching into AArch32
> > EL2 instead of AArch64 EL2 is an easy option to add.
> 
> I think the biggest difficulty is not the code to actually
> do the switch but figuring out what the command line
> UI to request "start in AArch32" ought to be and how that
> then gets plumbed into the code to do the actual work.

Out of interest, how do you do this on real hardware?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml"
  2014-08-07 15:06               ` Richard W.M. Jones
@ 2014-08-07 15:39                 ` Peter Maydell
  0 siblings, 0 replies; 12+ messages in thread
From: Peter Maydell @ 2014-08-07 15:39 UTC (permalink / raw)
  To: Richard W.M. Jones; +Cc: Christopher Covington, QEMU Developers

On 7 August 2014 16:06, Richard W.M. Jones <rjones@redhat.com> wrote:
> On Thu, Aug 07, 2014 at 02:53:33PM +0100, Peter Maydell wrote:
>> I think the biggest difficulty is not the code to actually
>> do the switch but figuring out what the command line
>> UI to request "start in AArch32" ought to be and how that
>> then gets plumbed into the code to do the actual work.
>
> Out of interest, how do you do this on real hardware?

Depends what level you're thinking at. At the absolute
lowest level, the Cortex-A57 for instance has an input
signal that's sampled on reset that indicates whether it
starts in AArch32 or AArch64. (In QEMU terms that would
be a CPU QOM property.) I'd expect that most boards
in practice would just hardwire that, though, since the
first thing that runs is going to be board-specific bootrom
code and having that be multi-width would be pointless
when you can just have the bootrom start EL2 in
AArch32 if it really needs to.

I don't know what the typical boot loader does. For
UEFI the files it boots are PE/COFF so in theory
it could look at the header (but I'm told that at the
moment 64-bit UEFI simply assumes 64-bit kernels).
I think u-boot also currently assumes 64-bit kernels
if it's a 64-bit u-boot.

Basically virtual machines are about the only place
where you'd actually want to run a 32 bit kernel if
your hardware supports 64 bit. So the only precedent
we have here is kvmtool, which currently requires
you to pass a command line argument if you want
your 64-bit guest CPU to start in AArch32.

thanks
-- PMM

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2014-08-07 15:39 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-07 10:42 [Qemu-devel] aarch64 & gdb: warning: while parsing target description (at line 1): Could not load XML document "arm-core.xml" Richard W.M. Jones
2014-08-07 11:18 ` Peter Maydell
2014-08-07 11:29   ` Richard W.M. Jones
2014-08-07 11:35     ` Peter Maydell
2014-08-07 11:43       ` Richard W.M. Jones
2014-08-07 12:03         ` Peter Maydell
2014-08-07 13:43           ` Christopher Covington
2014-08-07 13:53             ` Peter Maydell
2014-08-07 14:13               ` Christopher Covington
2014-08-07 14:53                 ` Peter Maydell
2014-08-07 15:06               ` Richard W.M. Jones
2014-08-07 15:39                 ` Peter Maydell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).