Folks,
Here's an update to the config-arm-generic in the scratch build from earlier. Once again, I insist (please) that we build in MMCI. If you look at the other configs (tegra,omap...) you'll see plenty of options that are overridden. Yes, we'll fix it so it can be a module in due course, but for the beta, and for now this is required in order to use hardware that is *always* present on vexpress. Just built in in please.
I've a scratch build going. It's possible something else is at fault, but hopefully that will prove this is the only change needed.
Jon.
On Wed, May 16, 2012 at 7:31 AM, Jon Masters jcm@redhat.com wrote:
Folks,
Here's an update to the config-arm-generic in the scratch build from earlier. Once again, I insist (please) that we build in MMCI. If you look at the other configs (tegra,omap...) you'll see plenty of options that are overridden. Yes, we'll fix it so it can be a module in due course, but for the beta, and for now this is required in order to use hardware that is *always* present on vexpress. Just built in in please.
John if you look at the upstream vexpress config it _IS_ now built in, I've already told you this in at least two different forums. I also added the core MMC as built in too.
I've a scratch build going. It's possible something else is at fault, but hopefully that will prove this is the only change needed.
I don't believe it is the only option and I've spent a couple of hours diffing your config to the one we generate and I can't see anything of relevance that is now different.
Peter
On 05/16/2012 08:55 AM, Peter Robinson wrote:
On Wed, May 16, 2012 at 7:31 AM, Jon Masters jcm@redhat.com wrote:
Folks,
Here's an update to the config-arm-generic in the scratch build from earlier. Once again, I insist (please) that we build in MMCI. If you look at the other configs (tegra,omap...) you'll see plenty of options that are overridden. Yes, we'll fix it so it can be a module in due course, but for the beta, and for now this is required in order to use hardware that is *always* present on vexpress. Just built in in please.
John if you look at the upstream vexpress config it _IS_ now built in, I've already told you this in at least two different forums. I also added the core MMC as built in too.
Sorry Peter. I guess I was looking at Dennis' scratch build, which still has it as a module, and he and I had a related dialog about that. In my checkout of the "f17" kernel branch, I'm still seeing:
config-arm-generic:CONFIG_MMC_ARMMMCI=m
Let's sync on IRC and do some collective digging on this. I'm obviously missing something :)
Jon.
On Wed, May 16, 2012 at 02:31:13AM -0400, Jon Masters wrote:
Folks,
Here's an update to the config-arm-generic in the scratch build from earlier. Once again, I insist (please) that we build in MMCI. If you look at the other configs (tegra,omap...) you'll see plenty of options that are overridden. Yes, we'll fix it so it can be a module in due course, but for the beta, and for now this is required in order to use hardware that is *always* present on vexpress. Just built in in please.
I've a scratch build going. It's possible something else is at fault, but hopefully that will prove this is the only change needed.
No virtio at all? I've not used it, but there's a virtio-mmio module upstream since 2011-10. If it compiles, please add it to the config, even if it doesn't function -- I'll test it.
Rich.
(That is, all virtio-* modules that can compile on ARM/vexpress.)
Rich.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Wed, 16 May 2012 23:01:08 +0100 "Richard W.M. Jones" rjones@redhat.com escribió:
(That is, all virtio-* modules that can compile on ARM/vexpress.)
Rich.
all the virtio modules are built. they get inherited from the generic kernel config. it just needs testing. it would be great to get things just working in libvirt/virt-manager took me a few hours today to do a "yum install totem" on the X image.
Dennis
On 05/16/2012 05:59 PM, Richard W.M. Jones wrote:
No virtio at all? I've not used it, but there's a virtio-mmio module upstream since 2011-10. If it compiles, please add it to the config, even if it doesn't function -- I'll test it.
We'll turn it on, and we'll test it. Let me take a moment to preach on something - not directed at anyone in particular :)
In the ARM world, we're going to increasingly see emulation for upcoming platforms. Versatile Express is real hardware that is emulated by the qemu-system-arm process. There is a fork for A15 (40-bit PA use) hardware and there will be v8 models at some point for 64-bit. All of these emulate real, physical hardware.
In the x86 world, there are two uses for qemu in particular. There is the original use of qemu as a system or process emulator, and there is the use of qemu as a backing container for the driver and IO virt. side of hardware and para-virtualization. In that case, it's not real emulation, it's just that qemu has never really been split out (yes, stuff was happening there in the kernel community) such that something not called "qemu" was seen as the virtualization IO container.
All this means that when we say "qemu", the first thing most people in the Fedora - or even broader - community think of is virtualization, not system emulation. Conversely, when I say qemu in the ARM space I mean specifically emulation of a specific hardware platform. Thus, when I am talking about qemu I am thinking of "that which models a physical piece of hardware called Versatile Express", which does not do virtio, does not do PCI, and does not have many other pieces of hardware that we're getting requests to add into that model. I'm ok with considering adding them, but it won't be vexpress after we're done. It'll be "some qemu-like thing with virtio". It seems that that is what we want, and virtio will buy us lots of benefits, BUT let's be clear when we discuss these things in the ARM space that qemu does not intrinstically mean "vritualization". Otherwise we're going to get very confused/ing.
Thanks - not a criticism, but something I feel needed clarifying.
Jon.
On Thu, May 17, 2012 at 02:01:51PM -0400, Jon Masters wrote:
On 05/16/2012 05:59 PM, Richard W.M. Jones wrote:
No virtio at all? I've not used it, but there's a virtio-mmio module upstream since 2011-10. If it compiles, please add it to the config, even if it doesn't function -- I'll test it.
We'll turn it on, and we'll test it. Let me take a moment to preach on something - not directed at anyone in particular :)
In the ARM world, we're going to increasingly see emulation for upcoming platforms. Versatile Express is real hardware that is emulated by the qemu-system-arm process. There is a fork for A15 (40-bit PA use) hardware and there will be v8 models at some point for 64-bit. All of these emulate real, physical hardware.
In the x86 world, there are two uses for qemu in particular. There is the original use of qemu as a system or process emulator, and there is the use of qemu as a backing container for the driver and IO virt. side of hardware and para-virtualization. In that case, it's not real emulation, it's just that qemu has never really been split out (yes, stuff was happening there in the kernel community) such that something not called "qemu" was seen as the virtualization IO container.
All this means that when we say "qemu", the first thing most people in the Fedora - or even broader - community think of is virtualization, not system emulation. Conversely, when I say qemu in the ARM space I mean specifically emulation of a specific hardware platform. Thus, when I am talking about qemu I am thinking of "that which models a physical piece of hardware called Versatile Express", which does not do virtio, does not do PCI, and does not have many other pieces of hardware that we're getting requests to add into that model. I'm ok with considering adding them, but it won't be vexpress after we're done. It'll be "some qemu-like thing with virtio". It seems that that is what we want, and virtio will buy us lots of benefits, BUT let's be clear when we discuss these things in the ARM space that qemu does not intrinstically mean "vritualization". Otherwise we're going to get very confused/ing.
Thanks - not a criticism, but something I feel needed clarifying.
I agree completely with the thrust of your point: ARM folk use qemu to accurately emulate systems that they don't have hardware for.
I'm aiming to get our virtualization stack working on ARM, so I'm definitely trying to get virtualization to work, just like it does on x86.
Actually I don't much care if it's added to the vexpress model, or if we have a special model for virtualization (let's have one without arbitrary memory limits ...). I have always felt that virtualizing specific hardware features is a poor decision, mainly done as a reaction against Xen and because of Windows and other closed-source things.
Rich.
On 05/17/2012 02:15 PM, Richard W.M. Jones wrote:
Actually I don't much care if it's added to the vexpress model, or if we have a special model for virtualization (let's have one without arbitrary memory limits ...). I have always felt that virtualizing specific hardware features is a poor decision, mainly done as a reaction against Xen and because of Windows and other closed-source things.
Yea. I've spoken with Linaro folks about coming up with a standard virt model for reference - right now, I think it's going to be vexpress based just due to lack of anyone driving something else. That's something, but it's not quite what I wanted. Still, if we can find a way to have some distinguishing term or package for the virtio/virt lightweight target that isn't the system emulation bit...cool. Let's ponder this some more and eventually we'll get there.
btw, I'll followup with you internally about access to A15 models. We might be able to do something with that in due course.
Jon.
-
Dennis Gilmore -
Jon Masters -
Peter Robinson -
Richard W.M. Jones