pseries: Add compatible property to root of device tree

Currently, for the pseries machine the device tree supplied by qemu to SLOF
and from there to the guest does not include a 'compatible property' at the
root level.  Usually that works fine, since in this case the compatible
property doesn't really give any information not already found in the
'device_type' or 'model' properties.

However, the lack of 'compatible' confuses the bootloader install in the
SLES11 SP2 and SLES11 SP3 installers.  This patch therefore adds a token
'compatible' property to work around that.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
 hw/spapr.c |    1 +
 1 file changed, 1 insertion(+)

I wonder if this can be related with the problem I found some time ago
while installing SLES.

http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00261.html

Regards,
Erlon

On Tue, Feb 26, 2013 at 2:27 AM, David Gibson
<david@gibson.dropbear.id.au>wrote:

> Currently, for the pseries machine the device tree supplied by qemu to SLOF
> and from there to the guest does not include a 'compatible property' at the
> root level.  Usually that works fine, since in this case the compatible
> property doesn't really give any information not already found in the
> 'device_type' or 'model' properties.
>
> However, the lack of 'compatible' confuses the bootloader install in the
> SLES11 SP2 and SLES11 SP3 installers.  This patch therefore adds a token
> 'compatible' property to work around that.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
>  hw/spapr.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/spapr.c b/hw/spapr.c
> index e88a27a..fadf70f 100644
> --- a/hw/spapr.c
> +++ b/hw/spapr.c
> @@ -260,6 +260,7 @@ static void *spapr_create_fdt_skel(const char
> *cpu_model,
>      _FDT((fdt_begin_node(fdt, "")));
>      _FDT((fdt_property_string(fdt, "device_type", "chrp")));
>      _FDT((fdt_property_string(fdt, "model", "IBM pSeries (emulated by
> qemu)")));
> +    _FDT((fdt_property_string(fdt, "compatible", "qemu,pseries")));
>
>      _FDT((fdt_property_cell(fdt, "#address-cells", 0x2)));
>      _FDT((fdt_property_cell(fdt, "#size-cells", 0x2)));
> --
> 1.7.10.4
>
>
>

On Tue, Feb 26, 2013 at 07:15:57AM -0300, Erlon Cruz wrote:
> I wonder if this can be related with the problem I found some time ago
> while installing SLES.
> 
> http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00261.html

Ah.  No, it's not.

I'm guessing you hit that problem running in full emulation on an x86
host?

I've hit the same bug - we're actually getting an illegal instruction
during the execution of the postinstall scripts.  Very odd.  Obviously
a bug in TCG, but I haven't managed to track it down.  It's not as
simple as an obscure instruction that wasn't implemented in TCG, it
appears to be a genuinely illegal instruction, which suggests guest
memory or register corruption.  I haven't managed to track it down any
further than that, because of course being full emulation it takes
ages to get to that point in the install after each new bit of
instrumentation, and other bugs have taken priority.

On 26.02.2013, at 11:15, Erlon Cruz wrote:

> I wonder if this can be related with the problem I found some time ago while installing SLES.
> 
> http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00261.html

Please don't top post.

IIRC this is a TCG related issue that David also debugged. David, did you manage to track down what was causing this?


Alex

On Tue, Feb 26, 2013 at 8:24 AM, David Gibson
<david@gibson.dropbear.id.au>wrote:

> On Tue, Feb 26, 2013 at 07:15:57AM -0300, Erlon Cruz wrote:
> > I wonder if this can be related with the problem I found some time ago
> > while installing SLES.
> >
> > http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00261.html
>
> Ah.  No, it's not.
>
> I'm guessing you hit that problem running in full emulation on an x86
> host?
>
>
Yes.


> I've hit the same bug - we're actually getting an illegal instruction
> during the execution of the postinstall scripts.  Very odd.  Obviously
> a bug in TCG, but I haven't managed to track it down.  It's not as
> simple as an obscure instruction that wasn't implemented in TCG, it
> appears to be a genuinely illegal instruction, which suggests guest
> memory or register corruption.  I haven't managed to track it down any
> further than that, because of course being full emulation it takes
> ages to get to that point in the install after each new bit of
> instrumentation, and other bugs have taken priority.
>
> --
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_
> _other_
>                                 | _way_ _around_!
> http://www.ozlabs.org/~dgibson
>