RE: RFC: top level compatibles for virtual platforms
> -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 > Herrenschmidt; Gala Kumar- > B11780; Alexander Graf; linuxppc-...@ozlabs.org > Subject: Re: RFC: top level compatibles for virtual platforms > > On Mon, 11 Jul 2011 15:41:35 -0500 > Yoder Stuart-B08248 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). 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
On Mon, 11 Jul 2011 15:41:35 -0500 Yoder Stuart-B08248 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
> -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
> Herrenschmidt; Gala Kumar-
> B11780; Alexander Graf; linuxppc-...@ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
>
> On Mon, 11 Jul 2011 12:41:20 -0500
> Yoder Stuart-B08248 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-...@ozlabs.org
> > > Subject: Re: RFC: top level compatibles for virtual platforms
> > >
> > > On Mon, 11 Jul 2011 10:45:47 -0500
> > > Timur Tabi 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).
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
On Tue, 12 Jul 2011 04:59:33 +0900 Grant Likely 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
On Mon, Jul 11, 2011 at 11:34 PM, Yoder Stuart-B08248 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-...@ozlabs.org >> Subject: Re: RFC: top level compatibles for virtual platforms >> >> On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 >> wrote: >> >> > "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 >> >> 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. > > 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. > >> 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. > > 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" 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
On Mon, 11 Jul 2011 12:41:20 -0500
Yoder Stuart-B08248 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-...@ozlabs.org
> > Subject: Re: RFC: top level compatibles for virtual platforms
> >
> > On Mon, 11 Jul 2011 10:45:47 -0500
> > Timur Tabi 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
> -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-...@ozlabs.org
> Subject: Re: RFC: top level compatibles for virtual platforms
>
> On Mon, 11 Jul 2011 10:45:47 -0500
> Timur Tabi 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':
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(). We need a way to
select the machine.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
On Mon, 11 Jul 2011 10:45:47 -0500 Timur Tabi 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
> -Original Message- > From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant > 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-...@ozlabs.org > Subject: Re: RFC: top level compatibles for virtual platforms > > On Friday, July 8, 2011, Tabi Timur-B04825 wrote: > > On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 > > wrote: > > > >> "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 > > > > 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? > > 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 ePAPR 1.1) describes hypervisor specific info. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
> -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-...@ozlabs.org > Subject: Re: RFC: top level compatibles for virtual platforms > > On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 > wrote: > > > "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 > > 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. 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. > 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. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
On Friday, July 8, 2011, Tabi Timur-B04825 wrote: > On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 > wrote: > >> "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 > > 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? I would say so. That would accurately describe the execution environment. > > -- > Timur Tabi > Linux kernel developer at Freescale > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RFC: top level compatibles for virtual platforms
On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 wrote: > "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 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? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
