RFC: top level compatibles for virtual platforms

RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

With KVM on Freescale booke parts we have currently two general types of
virtual platforms-- 1) an 85xx-like platform with e500v2 cpus,
etc, and 2) a P4080-like platform with a corenet based bus.

Today QEMU passes through to the guest a device tree with
a top level compatible of either "MPC8544DS", or "fsl,P4080DS".
These work but neither is quite accurate this is used on all targets
regardless of the underlying physical hardware.  Also, the guest
device tree represents virtual devices as well as a subset of the
cpus, memory, and devices on the hardware platform.

So continuing to use "MPC8544DS" or "fsl,P4080DS" compatible for all QEMU/K=
VM
created virtual machines is misleading and seems hackish.  They are
compatible to a degree, but the virtual platform would typically
be quite different.

What do you all think about creating some new somewhat generic=20
machine types in Linux to represent these 2 types of virtual
platforms.  Perhaps:

   "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
                 and would support 85xx targets, plus P2020, P1022,etc

   "corenet-32-ds" - for a virtual machine similar to the 32-bit P4080
                     platforms

   "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
                     platform


Thoughts?

Thanks,
Stuart Yoder

Re: RFC: top level compatibles for virtual platforms

[Tabi Timur-B04825]

On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248
<B08248@freescale.com> wrote:

> =A0 "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and would support 85xx targets, plus P202=
0, P1022,etc
>
> =A0 "corenet-32-ds" - for a virtual machine similar to the 32-bit P4080
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platforms
>
> =A0 "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platform

I think we should drop the "DS" because that's a name applied to
certain Freescale reference boards.

Is being a CoreNet board really something meaningful with respect to
KVM?  I don't see the connection.

Also, if these are KVM creations, shouldn't there be a "kvm" in the
compatible string somewhere?

--=20
Timur Tabi
Linux kernel developer at Freescale=

Re: RFC: top level compatibles for virtual platforms

[Grant Likely]

On Friday, July 8, 2011, Tabi Timur-B04825 <B04825@freescale.com> wrote:
> On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248
> <B08248@freescale.com> wrote:
>
>> =A0 "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and would support 85xx targets, plus P20=
20, P1022,etc
>>
>> =A0 "corenet-32-ds" - for a virtual machine similar to the 32-bit P4080
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platforms
>>
>> =A0 "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platform
>
> I think we should drop the "DS" because that's a name applied to
> certain Freescale reference boards.
>
> Is being a CoreNet board really something meaningful with respect to
> KVM? =A0I don't see the connection.
>
> Also, if these are KVM creations, shouldn't there be a "kvm" in the
> compatible string somewhere?

I would say so. That would accurately describe the execution environment.

>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Gra=
nt Likely
> Sent: Friday, July 08, 2011 9:42 PM
> To: Tabi Timur-B04825
> Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala Kumar=
-B11780; Wood Scott-
> B07421; Alexander Graf; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
>=20
> On Friday, July 8, 2011, Tabi Timur-B04825 <B04825@freescale.com> wrote:
> > On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248
> > <B08248@freescale.com> wrote:
> >
> >> =A0 "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and would support 85xx targets, plus P=
2020, P1022,etc
> >>
> >> =A0 "corenet-32-ds" - for a virtual machine similar to the 32-bit P408=
0
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platforms
> >>
> >> =A0 "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platform
> >
> > I think we should drop the "DS" because that's a name applied to
> > certain Freescale reference boards.
> >
> > Is being a CoreNet board really something meaningful with respect to
> > KVM? =A0I don't see the connection.
> >
> > Also, if these are KVM creations, shouldn't there be a "kvm" in the
> > compatible string somewhere?
>=20
> I would say so. That would accurately describe the execution environment.

As I mentioned to Timur, there is nothing KVM specific about
the execution environment.   The /hypervisor node (as per=20
ePAPR 1.1) describes hypervisor specific info.

Stuart

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Tabi Timur-B04825
> Sent: Friday, July 08, 2011 8:39 PM
> To: Yoder Stuart-B08248
> Cc: Grant Likely; Benjamin Herrenschmidt; Gala Kumar-B11780; Wood Scott-B=
07421; Alexander
> Graf; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
>=20
> On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 <B08248@freescale.com=
> wrote:
>=20
> > =A0 "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and would support 85xx targets, plus P2=
020, P1022,etc
> >
> > =A0 "corenet-32-ds" - for a virtual machine similar to the 32-bit P4080
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platforms
> >
> > =A0 "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platform
>=20
> I think we should drop the "DS" because that's a name applied to certain =
Freescale reference
> boards.
>=20
> Is being a CoreNet board really something meaningful with respect to KVM?=
  I don't see the
> connection.

We're talking about what would be meaningful to Linux as a guest on
this platform here--  Corenet-based SoCs are similar=20
in various ways, like using msgsnd for IPIs, having external proxy
support, etc.

A corenet platform created by a QEMU/KVM looks similar
to other corenet SoCs.   So, I'm trying to find some generic
compatible string that describes this platform.

> Also, if these are KVM creations, shouldn't there be a "kvm" in the compa=
tible string
> somewhere?

There is nothing KVM specific about these platforms.  Any hypervisor
could create a similar virtual machine.

A guest OS can determine specific info about the hypervisor it is
running on by looking at the /hypervisor node on the device
tree.

We could put a generic -hv extension to indicate that this is
a virtual platform.

 "mpc85xx-hv"
 "corenet-32-hv"
 "corenet-64-hv"

Stuart

Re: RFC: top level compatibles for virtual platforms

[Timur Tabi]

Yoder Stuart-B08248 wrote:

> We're talking about what would be meaningful to Linux as a guest on
> this platform here--  Corenet-based SoCs are similar 
> in various ways, like using msgsnd for IPIs, having external proxy
> support, etc.
> 
> A corenet platform created by a QEMU/KVM looks similar
> to other corenet SoCs.   So, I'm trying to find some generic
> compatible string that describes this platform.

Is there a list of these features that are 100% guaranteed to belong to a
corenet platform?

I'm just not comfortable using "corenet" as a basis for a feature set that has
nothing to do with coherency.

>> Also, if these are KVM creations, shouldn't there be a "kvm" in the compatible string
>> somewhere?
> 
> There is nothing KVM specific about these platforms.  Any hypervisor
> could create a similar virtual machine.

True, but I think we're on a slippery slope, here.  Virtualization allows us to
create "virtual platforms" that are not well defined.  Linux requires a unique
compatible string for each platform.  That's easy when we ship a reference board
that has a unique name and a fixed, well-defined set of features.  But with
these virtual platforms, what does the name mean?

I guess my point is back to the name "corenet".  That just doesn't mean anything
to me, and I don't think it means much to anyone else, either.  That's why I
think that maybe "kvm" should be in the string, to at least indicate that it's a
virtualized environment.

> A guest OS can determine specific info about the hypervisor it is
> running on by looking at the /hypervisor node on the device
> tree.
> 
> We could put a generic -hv extension to indicate that this is
> a virtual platform.
> 
>  "mpc85xx-hv"
>  "corenet-32-hv"
>  "corenet-64-hv"

That's an improvement, but I wonder if we should just keep doing what we do with
Topaz: take the actual hardware platform and add -hv to it.  Of course, that
conflicts with Topaz at the moment.

-- 
Timur Tabi
Linux kernel developer at Freescale

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: RFC: top level compatibles for virtual platforms

[Scott Wood]

On Mon, 11 Jul 2011 10:45:47 -0500
Timur Tabi <timur@freescale.com> wrote:

> >> Also, if these are KVM creations, shouldn't there be a "kvm" in the compatible string
> >> somewhere?
> > 
> > There is nothing KVM specific about these platforms.  Any hypervisor
> > could create a similar virtual machine.
> 
> True, but I think we're on a slippery slope, here.  Virtualization allows us to
> create "virtual platforms" that are not well defined.  Linux requires a unique
> compatible string for each platform.

The device tree is supposed to describe the hardware (virtual or
otherwise), not just supply what Linux wants.  Perhaps there simply
shouldn't be a toplevel compatible if there's nothing appropriate to
describe there -- and fix whatever issues Linux has with that.

> I guess my point is back to the name "corenet".  That just doesn't mean anything
> to me, and I don't think it means much to anyone else, either.  That's why I
> think that maybe "kvm" should be in the string, to at least indicate that it's a
> virtualized environment.

But what about this is specific to kvm (the actual hypervisor info is
already described in /hypervisor)?  Then we'll have to add a platform match
for every other hypervisor out there that does the same thing.

-Scott

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Monday, July 11, 2011 11:24 AM
> To: Tabi Timur-B04825
> Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala Kumar=
-B11780; Wood Scott-
> B07421; Alexander Graf; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
>=20
> On Mon, 11 Jul 2011 10:45:47 -0500
> Timur Tabi <timur@freescale.com> wrote:
>=20
> > >> Also, if these are KVM creations, shouldn't there be a "kvm" in the
> > >> compatible string somewhere?
> > >
> > > There is nothing KVM specific about these platforms.  Any hypervisor
> > > could create a similar virtual machine.
> >
> > True, but I think we're on a slippery slope, here.  Virtualization
> > allows us to create "virtual platforms" that are not well defined.
> > Linux requires a unique compatible string for each platform.
>=20
> The device tree is supposed to describe the hardware (virtual or otherwis=
e), not just supply
> what Linux wants.  Perhaps there simply shouldn't be a toplevel compatibl=
e if there's nothing
> appropriate to describe there -- and fix whatever issues Linux has with t=
hat.

But there is a concept in Linux of a platform 'machine':

define_machine(p4080_ds) {
        .name                   =3D "P4080 DS",
        .probe                  =3D p4080_ds_probe,
        .setup_arch             =3D corenet_ds_setup_arch,
        .init_IRQ               =3D corenet_ds_pic_init,
#ifdef CONFIG_PCI
        .pcibios_fixup_bus      =3D fsl_pcibios_fixup_bus,
#endif
        .get_irq                =3D mpic_get_coreint_irq,
        .restart                =3D fsl_rstcr_restart,
        .calibrate_decr         =3D generic_calibrate_decr,
        .progress               =3D udbg_progress,
};

Right now p4080_ds_probe needs something to match on to determine
whether this is the machine type.   How would it work if=20
there was no top level compatible to match on?   Some=20
platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(),
others need corenet_ds_pic_init().  We need a way to
select the machine.

Stuart

Re: RFC: top level compatibles for virtual platforms

[Scott Wood]

On Mon, 11 Jul 2011 12:41:20 -0500
Yoder Stuart-B08248 <B08248@freescale.com> wrote:

> 
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Monday, July 11, 2011 11:24 AM
> > To: Tabi Timur-B04825
> > Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala Kumar-B11780; Wood Scott-
> > B07421; Alexander Graf; linuxppc-dev@ozlabs.org
> > Subject: Re: RFC: top level compatibles for virtual platforms
> > 
> > On Mon, 11 Jul 2011 10:45:47 -0500
> > Timur Tabi <timur@freescale.com> wrote:
> > 
> > > >> Also, if these are KVM creations, shouldn't there be a "kvm" in the
> > > >> compatible string somewhere?
> > > >
> > > > There is nothing KVM specific about these platforms.  Any hypervisor
> > > > could create a similar virtual machine.
> > >
> > > True, but I think we're on a slippery slope, here.  Virtualization
> > > allows us to create "virtual platforms" that are not well defined.
> > > Linux requires a unique compatible string for each platform.
> > 
> > The device tree is supposed to describe the hardware (virtual or otherwise), not just supply
> > what Linux wants.  Perhaps there simply shouldn't be a toplevel compatible if there's nothing
> > appropriate to describe there -- and fix whatever issues Linux has with that.
> 
> But there is a concept in Linux of a platform 'machine':

So have a Linux "machine" that is used when no other one matches.  That
doesn't justify making something up in the device tree.

> define_machine(p4080_ds) {
>         .name                   = "P4080 DS",
>         .probe                  = p4080_ds_probe,
>         .setup_arch             = corenet_ds_setup_arch,
>         .init_IRQ               = corenet_ds_pic_init,
> #ifdef CONFIG_PCI
>         .pcibios_fixup_bus      = fsl_pcibios_fixup_bus,
> #endif
>         .get_irq                = mpic_get_coreint_irq,
>         .restart                = fsl_rstcr_restart,
>         .calibrate_decr         = generic_calibrate_decr,
>         .progress               = udbg_progress,
> };
> 
> Right now p4080_ds_probe needs something to match on to determine
> whether this is the machine type.   How would it work if 
> there was no top level compatible to match on?   Some 
> platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(),
> others need corenet_ds_pic_init().

Just because Linux does it that way now doesn't mean it needs to.  The
interrupt controller has a compatible property.  Match on it like any other
device.  You can find which one is the root interrupt controller by looking
for nodes with the interrupt-controller property that doesn't have an
explicit interrupt-parent (or an interrupts property?  seems to be a
conflict between ePAPR and the original interrupt mapping document).

-Scott

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Monday, July 11, 2011 1:05 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Tabi Timur-B04825; Grant Likely; Benjamin Herrensc=
hmidt; Gala Kumar-
> B11780; Alexander Graf; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
>=20
> On Mon, 11 Jul 2011 12:41:20 -0500
> Yoder Stuart-B08248 <B08248@freescale.com> wrote:
>=20
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Monday, July 11, 2011 11:24 AM
> > > To: Tabi Timur-B04825
> > > Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala
> > > Kumar-B11780; Wood Scott- B07421; Alexander Graf;
> > > linuxppc-dev@ozlabs.org
> > > Subject: Re: RFC: top level compatibles for virtual platforms
> > >
> > > On Mon, 11 Jul 2011 10:45:47 -0500
> > > Timur Tabi <timur@freescale.com> wrote:
> > >
> > > > >> Also, if these are KVM creations, shouldn't there be a "kvm" in
> > > > >> the compatible string somewhere?
> > > > >
> > > > > There is nothing KVM specific about these platforms.  Any
> > > > > hypervisor could create a similar virtual machine.
> > > >
> > > > True, but I think we're on a slippery slope, here.  Virtualization
> > > > allows us to create "virtual platforms" that are not well defined.
> > > > Linux requires a unique compatible string for each platform.
> > >
> > > The device tree is supposed to describe the hardware (virtual or
> > > otherwise), not just supply what Linux wants.  Perhaps there simply
> > > shouldn't be a toplevel compatible if there's nothing appropriate to =
describe there -- and
> fix whatever issues Linux has with that.
> >
> > But there is a concept in Linux of a platform 'machine':
>=20
> So have a Linux "machine" that is used when no other one matches.  That d=
oesn't justify making
> something up in the device tree.
>=20
> > define_machine(p4080_ds) {
> >         .name                   =3D "P4080 DS",
> >         .probe                  =3D p4080_ds_probe,
> >         .setup_arch             =3D corenet_ds_setup_arch,
> >         .init_IRQ               =3D corenet_ds_pic_init,
> > #ifdef CONFIG_PCI
> >         .pcibios_fixup_bus      =3D fsl_pcibios_fixup_bus,
> > #endif
> >         .get_irq                =3D mpic_get_coreint_irq,
> >         .restart                =3D fsl_rstcr_restart,
> >         .calibrate_decr         =3D generic_calibrate_decr,
> >         .progress               =3D udbg_progress,
> > };
> >
> > Right now p4080_ds_probe needs something to match on to determine
> > whether this is the machine type.   How would it work if
> > there was no top level compatible to match on?   Some
> > platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(), others need
> > corenet_ds_pic_init().
>=20
> Just because Linux does it that way now doesn't mean it needs to.  The in=
terrupt controller
> has a compatible property.  Match on it like any other device.  You can f=
ind which one is the
> root interrupt controller by looking for nodes with the interrupt-control=
ler property that
> doesn't have an explicit interrupt-parent (or an interrupts property?  se=
ems to be a conflict
> between ePAPR and the original interrupt mapping document).

This may be the right long term thing to do, but restructuring
how Linux powerpc platforms work is a bigger effort.  I was looking
for an incremental improvement over what we do now, which is pass
a compatible of MPC8544DS and P4080DS for these virtual platforms.

However, they _are_ compatible with MPC8544DS and P4080DS so maybe
leaving the compatible string alone is ok for now.

Stuart

Re: RFC: top level compatibles for virtual platforms

[Scott Wood]

On Mon, 11 Jul 2011 15:41:35 -0500
Yoder Stuart-B08248 <B08248@freescale.com> wrote:

> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Monday, July 11, 2011 1:05 PM
> > 
> > Just because Linux does it that way now doesn't mean it needs to.  The interrupt controller
> > has a compatible property.  Match on it like any other device.  You can find which one is the
> > root interrupt controller by looking for nodes with the interrupt-controller property that
> > doesn't have an explicit interrupt-parent (or an interrupts property?  seems to be a conflict
> > between ePAPR and the original interrupt mapping document).
> 
> This may be the right long term thing to do, but restructuring
> how Linux powerpc platforms work is a bigger effort.  I was looking
> for an incremental improvement over what we do now, which is pass
> a compatible of MPC8544DS and P4080DS for these virtual platforms.

A hack is usually easier than doing it right. :-)

Though often the effort required for the latter is overstated, and the
"right long term thing" never makes the jump to "short term plan".

There are a few things that need to be driven off the device tree that
currently aren't -- using some mechanism other than the standard
device model, if necessary (or as a first step) -- and then we need a
does-nothing default platform as the match of last resort.

> However, they _are_ compatible with MPC8544DS and P4080DS so maybe
> leaving the compatible string alone is ok for now.

The virtual platforms are not compatible with MPC8544DS or P4080DS.  Only a
subset of what is on those boards is provided.  And in the case of direct
device assignment, often the things that are present are incompatible (e.g.
different type of eTSEC).

-Scott

RE: RFC: top level compatibles for virtual platforms

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Monday, July 11, 2011 4:07 PM
> To: Yoder Stuart-B08248
> Cc: Wood Scott-B07421; Tabi Timur-B04825; Grant Likely; Benjamin Herrensc=
hmidt; Gala Kumar-
> B11780; Alexander Graf; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
>=20
> On Mon, 11 Jul 2011 15:41:35 -0500
> Yoder Stuart-B08248 <B08248@freescale.com> wrote:
>=20
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Monday, July 11, 2011 1:05 PM
> > >
> > > Just because Linux does it that way now doesn't mean it needs to.
> > > The interrupt controller has a compatible property.  Match on it
> > > like any other device.  You can find which one is the root interrupt
> > > controller by looking for nodes with the interrupt-controller
> > > property that doesn't have an explicit interrupt-parent (or an interr=
upts property?  seems
> to be a conflict between ePAPR and the original interrupt mapping documen=
t).
> >
> > This may be the right long term thing to do, but restructuring how
> > Linux powerpc platforms work is a bigger effort.  I was looking for an
> > incremental improvement over what we do now, which is pass a
> > compatible of MPC8544DS and P4080DS for these virtual platforms.
>=20
> A hack is usually easier than doing it right. :-)
>=20
> Though often the effort required for the latter is overstated, and the "r=
ight long term thing"
> never makes the jump to "short term plan".
>=20
> There are a few things that need to be driven off the device tree that cu=
rrently aren't --
> using some mechanism other than the standard device model, if necessary (=
or as a first step) -
> - and then we need a does-nothing default platform as the match of last r=
esort.
>=20
> > However, they _are_ compatible with MPC8544DS and P4080DS so maybe
> > leaving the compatible string alone is ok for now.
>=20
> The virtual platforms are not compatible with MPC8544DS or P4080DS.  Only=
 a subset of what is
> on those boards is provided.  And in the case of direct device assignment=
, often the things
> that are present are incompatible (e.g.
> different type of eTSEC).

Hmm.  Perhaps what we need is a real binding that defines specifically
what those compatibles mean.   While not identical, a KVM
virtual machine is compatible in certain areas with those
boards.

The ePAPR defines the top level compatible as:

    Specifies a list of platform architectures with which this
    platform is compatible. This property can be used by
    operating systems in selecting platform specific code.

1275 doesn't mention compatible on the root from what I can
see.

Stuart

Re: RFC: top level compatibles for virtual platforms

[Timur Tabi]

Scott Wood wrote:
> The device tree is supposed to describe the hardware (virtual or
> otherwise), not just supply what Linux wants.  Perhaps there simply
> shouldn't be a toplevel compatible if there's nothing appropriate to
> describe there -- and fix whatever issues Linux has with that.

That might be the way to go.  I wonder if we can get rid of the platform file
altogether, at least in some situations.

> But what about this is specific to kvm (the actual hypervisor info is
> already described in /hypervisor)?  Then we'll have to add a platform match
> for every other hypervisor out there that does the same thing.

I don't know enough about KVM to answer that question.

Frankly, I like the approach that Topaz takes -- add a "-hv" to the real
hardware platform.  The only drawback is that each platform needs to add support
for virtualization, but we already have this problem with Topaz today.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: RFC: top level compatibles for virtual platforms

[Grant Likely]

On Mon, Jul 11, 2011 at 11:34 PM, Yoder Stuart-B08248
<B08248@freescale.com> wrote:
>
>
>> -----Original Message-----
>> From: Tabi Timur-B04825
>> Sent: Friday, July 08, 2011 8:39 PM
>> To: Yoder Stuart-B08248
>> Cc: Grant Likely; Benjamin Herrenschmidt; Gala Kumar-B11780; Wood Scott-=
B07421; Alexander
>> Graf; linuxppc-dev@ozlabs.org
>> Subject: Re: RFC: top level compatibles for virtual platforms
>>
>> On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 <B08248@freescale.co=
m> wrote:
>>
>> > =A0 "MPC85xxDS" - for a virtual machine for the e500v2 type platforms
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and would support 85xx targets, plus P=
2020, P1022,etc
>> >
>> > =A0 "corenet-32-ds" - for a virtual machine similar to the 32-bit P408=
0
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platforms
>> >
>> > =A0 "corenet-64-ds" - for a virtual machine based on a 64-bit corenet
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 platform
>>
>> I think we should drop the "DS" because that's a name applied to certain=
 Freescale reference
>> boards.
>>
>> Is being a CoreNet board really something meaningful with respect to KVM=
? =A0I don't see the
>> connection.
>
> We're talking about what would be meaningful to Linux as a guest on
> this platform here-- =A0Corenet-based SoCs are similar
> in various ways, like using msgsnd for IPIs, having external proxy
> support, etc.
>
> A corenet platform created by a QEMU/KVM looks similar
> to other corenet SoCs. =A0 So, I'm trying to find some generic
> compatible string that describes this platform.
>
>> Also, if these are KVM creations, shouldn't there be a "kvm" in the comp=
atible string
>> somewhere?
>
> There is nothing KVM specific about these platforms. =A0Any hypervisor
> could create a similar virtual machine.
>
> A guest OS can determine specific info about the hypervisor it is
> running on by looking at the /hypervisor node on the device
> tree.
>
> We could put a generic -hv extension to indicate that this is
> a virtual platform.
>
> =A0"mpc85xx-hv"
> =A0"corenet-32-hv"
> =A0"corenet-64-hv"

However, compatible values are cheap and while theoretically any
hypervisor could create a similar machine, the reality is probably
subtle difference between the implementations.  I'd rather see the
compatible reflect the specific implementation.

g.

Re: RFC: top level compatibles for virtual platforms

[Scott Wood]

On Tue, 12 Jul 2011 04:59:33 +0900
Grant Likely <grant.likely@secretlab.ca> wrote:

> However, compatible values are cheap and while theoretically any
> hypervisor could create a similar machine, the reality is probably
> subtle difference between the implementations.  I'd rather see the
> compatible reflect the specific implementation.

That's what the hypervisor node is for.  We have a tree, let's use it. :-)

-Scott