Hi,
On 02/15/2018 02:39 PM, Peter Maydell wrote:
On 8 February 2018 at 05:50, Pekka Enberg wrote:
This patch adds a "raspi3" machine type, which can now be selected as
the machine to run on by users via the "-M" command line option to QEMU.
The machine type does
On 02/15/2018 01:48 PM, Peter Maydell wrote:
On 8 February 2018 at 05:50, Pekka Enberg wrote:
This patch adds a "cpu-type" property to BCM2836 SoC in preparation for
reusing the code for the Raspberry Pi 3, which has a different processor
model.
Signed-off-by: Pekka Enberg
--
itten from scratch by me but the logic is similar to
Zoltán Baldaszti's previous work, which I used as a reference (with
permission from the author):
https://github.com/bztsrc/qemu-raspi3
Signed-off-by: Pekka Enberg
---
hw/arm/raspi.c | 31 +--
1 file changed, 21
e run something
more complicated than what I'm using for testing.
Signed-off-by: Pekka Enberg
---
hw/arm/raspi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 66fe10e376..ff54f45e3e 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@
This patch adds a "cpu-type" property to BCM2836 SoC in preparation for
reusing the code for the Raspberry Pi 3, which has a different processor
model.
Signed-off-by: Pekka Enberg
---
hw/arm/bcm2836.c | 17 +
hw/arm/raspi.c | 3 +++
include/hw/arm
pberry Pi 3 machine definition with TARGET_AARCH64 (Peter
Maydell)
Pekka Enberg (3):
bcm2836: Make CPU type configurable
raspi: Raspberry Pi 3 support
raspi: Add "raspi3" machine type
hw/arm/bcm2836.c | 17 ---
hw/arm/raspi.c | 57 +++
itten from scratch by me but the logic is similar to
Zoltán Baldaszti's previous work, which I used as a reference (with
permission from the author):
https://github.com/bztsrc/qemu-raspi3
Signed-off-by: Pekka Enberg
---
hw/arm/raspi.c | 31 +--
1 file changed, 21
e run something
more complicated than what I'm using for testing.
Signed-off-by: Pekka Enberg
---
hw/arm/raspi.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 66fe10e376..048ff23a51 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@
ision is 0xa02082
The patches were written by me but I used Zoltán Baldaszti's previous
work as a reference (with permission from the author):
https://github.com/bztsrc/qemu-raspi3
Also available from:
g...@github.com:penberg/qemu.git raspi3/v1
Pekka Enberg (3):
bcm2836:
Hi,
On 02/02/2017 19.48, Ard Biesheuvel wrote:
$ git grep -C5 -ni 0x1DE7EC7EDBADC0DE
arch/arm64/kvm/sys_regs.h-105-static inline void reset_unknown(struct
kvm_vcpu *vcpu,
arch/arm64/kvm/sys_regs.h-106- const struct
sys_reg_desc *r)
arch/arm64/kvm/sys_regs.h-107-{
arch/a
Hi,
Has anyone been able to successfully run QEMU/KVM under Raspberry Pi 3?
I have installed 64-bit Fedora 24 by Gerd Hoffmann on the hardware:
https://www.kraxel.org/blog/2016/04/fedora-on-raspberry-pi-updates/
and built a VM image using virt-builder:
virt-builder --root-password passwor
Hello,
We're proud to announce release 0.01 of OSv, a new operating system
for running applications on virtual machines. OSv is free software,
released under the BSD license, and you can find it in
https://github.com/cloudius-systems/osv and http://www.osv.io.
To build and run OSv under KVM/QEMU,
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig wrote:
> Nevermind that running virtfs as a rootfs is a really dumb idea. You
> do now want to run a VM that has a rootfs that gets changed all the
> time behind your back.
It's rootfs binaries that are shared, not configuration. It's
unfortunate
On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak wrote:
>> I don't know if it makes sense to merge the tools you've mentioned above.
>> My gut feeling is that it's probably not reasonable - there's already a
>> community working on it with their own development process and coding
>> style. I don't think
On Tue, 8 Nov 2011, Frank Ch. Eigler wrote:
Almost: they demonstrate that those parts of the ABI that these
particular perf commands rely on have been impressively compatible.
Do you have any sort of ABI coverage measurement, to see what
parts of the ABI these perf commands do not use?
It's pre
On Tue, 8 Nov 2011, Theodore Tso wrote:
We have the staging tree because it's a widely acknowledged belief that
kernel code in the tree tends to improve over time compared to code
that's sitting out of the tree. Are you disputing that belief?
Kernel code in the kernel source tree improves; bec
On Tue, 8 Nov 2011, Theodore Tso wrote:
It's great to hear that! But in that case, there's an experiment we
can't really run, which is if perf had been developed in a separate
tree, would it have been just as successful?
Experiment, eh?
We have the staging tree because it's a widely acknowl
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o wrote:
> Personally, I consider code that runs in userspace as a pretty bright
> line, as being "not kernel code", and while perhaps things like
> initramfs and the crazy ideas people have had in the past of moving
> stuff out of kernel/init.c int
On Mon, 7 Nov 2011, Frank Ch. Eigler wrote:
The ABI design allows for that kind of flexible extensibility, and
it's one of its major advantages.
What we *cannot* protect against is you relying on obscure details of
the ABI [...]
Is there some documentation that clearly spells out which parts o
On Mon, 7 Nov 2011, Pekka Enberg wrote:
>> I've never heard ABI incompatibility used as an argument for perf. Ingo?
On Mon, Nov 7, 2011 at 7:03 PM, Vince Weaver wrote:
> Never overtly. They're too clever for that.
If you want me to take you seriously, spare me from the cons
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o wrote:
> I don't think perf should be used as a precendent that now argues that
> any new kernel utility should be moved into the kernel sources. Does
> it make sense to move all of mount, fsck, login, etc., into the kernel
> sources? There are far more k
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o wrote:
> Perf was IMHO an overreaction caused by the fact that systemtap and
> oprofile people packaged and released the sources in a way that kernel
> developers didn't like.
>
> I don't think perf should be used as a precendent that now argues that
> any
Hi Ted,
On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o wrote:
> And the same problems will exist with kvm-tool. What if you need to
> release a new version of kvm-tool? Does that mean that you have to
> release a new set of kernel binaries? It's a mess, and there's a
> reason why we don't have glibc
Hi Avi,
On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity wrote:
>> tools/power was merged in just 2 versions ago, do you think that
>> merging that was a mistake?
>
> Things like tools/power may make sense, most of the code is tied to the
> kernel interfaces. tools/kvm is 20k lines and is likely to be
On Mon, Nov 7, 2011 at 2:18 PM, Gerd Hoffmann wrote:
> tools/ lacks a separation into "kernel hacker's testing+debugging
> toolbox" and "userspace tools". It lacks proper buildsystem integration
> for the userspace tools, there is no "make tools" and also no "make
> tools_install". Silently drop
On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini wrote:
> Indeed I do not see any advantage, since all the interfaces they use are
> stable anyway (sysfs, msr.ko).
>
> If they had gone in x86info, for example, my distro (F16, not exactly
> conservative) would have likely picked those tools up already
On Mon, 7 Nov 2011, Kevin Wolf wrote:
Makes it a lot less hackable for me unless you want to restrict the set
of potential developers to Linux kernel developers...
We're not restricting potential developers to Linux kernel folks. We're
making it easy for them because we believe that the KVM to
On Mon, 7 Nov 2011, Gerd Hoffmann wrote:
It's not just about code, it's as much about culture and development process.
Indeed. The BSDs have both kernel and the base system in a single
repository. There are probably good reasons for (and against) it.
In Linux we don't have that culture. No
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann wrote:
> No support for booting from CDROM.
> No support for booting from Network.
> Thus no way to install a new guest image.
Sure. It's a pain point which we need to fix.
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann wrote:
> Booting an existing
On 11/07/2011 09:45 AM, Pekka Enberg wrote:
>>> Specifications matter much more than working code. Quirks are a fact
>>> of life but should always come second.
>>
>> To quote Linus:
>>
>> And I have seen _lots_ of total crap work that was based on spec
On 11/07/2011 09:09 AM, Pekka Enberg wrote:
We are obviously also using specifications but as you damn well should
know, specifications don't matter nearly as much as working code.
On Mon, 7 Nov 2011, Paolo Bonzini wrote:
Specifications matter much more than working code. Quirks are a fa
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini wrote:
> (BTW, I'm also convinced like Ted that not having a defined perf ABI might
> have made sense in the beginning, but it has now devolved into bad software
> engineering practice).
I'm not a perf maintainer so I don't know what the situation wi
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini wrote:
> No, having the source code in Linux kernel tree is perfectly useless for the
> exceptional case, and forces you to go through extra hoops to build only one
> component. Small hoops such as adding "-- tools/kvm" to "git bisect start"
> perhap
On Mon, Nov 7, 2011 at 12:08 AM, Frank Ch. Eigler wrote:
>> [...] We don't want to be different, we want to make the barrier of
>> entry low.
>
> When has the barrier of entry into the kernel ever been "low"
> for anyone not already working in the kernel?
What's your point? Working on the KVM to
Hi Anthony,
On Sun, 6 Nov 2011, Anthony Liguori wrote:
- Drop SDL/VNC. Make a proper Cairo GUI with a full blown GTK interface.
Don't rely on virt-manager for this. Not that I have anything against
virt-manager but there are many layers between you and the end GUI if you go
that route.
Fun
On Sun, 6 Nov 2011, Ted Ts'o wrote:
The only excuse I can see is a hope to make random changes to the
kernel and userspace tools without having to worry about compatibility
problems, which is an argument I've seen with perf (that you have to
use the same version of perf as the kernel version, whi
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini wrote:
> Nothing, but I'm just giving you *strong* hints that a submodule or a merged
> tool is the wrong solution, and the histories of kernel and tool should be
> kept separate.
And btw, I don't really understand what you're trying to accomplish
wi
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini wrote:
>> If you're bisecting breakage that can be in the guest kernel or the
>> KVM tool, you'd want to build both.
>
> No. I want to try new tool/old kernel and old tool/new kernel (kernel can
> be either guest or host, depending on the nature of t
On Sun, Nov 6, 2011 at 9:14 PM, Paolo Bonzini wrote:
> GStreamer (V4L), RTSAdmin (LIO target), sg3_utils, trousers all are out of
> tree, and nobody of their authors is even thinking of doing all this
> brouhaha to get merged into Linus's tree.
We'd be the first subsystem to use the download scri
On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini wrote:
>> I really don't see the point in doing that. We want to be part of
>> regular kernel history and release cycle.
>
> But I'm pretty certain that, when testing 3.2 with KVM tool in a couple of
> years, I want all the shining new features you add
On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg wrote:
>> So integrating kvm-tool into the kernel isn't going to work as a free
>> pass to make non-backwards compatible changes to the KVM user/kernel
>> interface. Given that, why bloat the kernel source tree size?
>
&
On Sun, Nov 06, 2011 at 11:08:10AM -0600, Anthony Liguori wrote:
>> I'm quite happy with KVM tool and hope they continue working on it.
>> My only real wish is that they wouldn't copy QEMU so much and would
>> try bolder things that are fundamentally different from QEMU.
On Sun, Nov 6, 2011 at 8:3
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori wrote:
> I'm quite happy with KVM tool and hope they continue working on it. My only
> real wish is that they wouldn't copy QEMU so much and would try bolder
> things that are fundamentally different from QEMU.
Hey, right now our only source of cra
On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf wrote:
>> That's pretty much what git submodule would do, isn't it?
>>
>> I really don't see the point in doing that. We want to be part of
>> regular kernel history and release cycle. We want people to be able to
>> see what's going on in our tree to
On Sun, 6 Nov 2011, Jan Kiszka wrote:
Doesn't help here (with a disk image).
Also, both dependencies make no sense to me as we boot from disk, not
from net, and the console is on ttyS0.
It's only VIRTIO_NET and the guest is not actually stuck, it just takes a
while to boot:
[1.866614] I
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf wrote:
>> The difference here is that although I feel Alex's script is a
>> pointless project, I'm in no way opposed to merging it in the tree if
>> people use it and it solves their problem. Some people seem to be
>> violently opposed to merging the
On Sun, 6 Nov 2011, Jan Kiszka wrote:
Can you please share your kernel .config with me and I'll take a look
at it. We now have a "make kvmconfig" makefile target for enabling all
the necessary config options for guest kernels. I don't think any of
us developers are using SUSE so it can surely be
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka wrote:
> In contrast, you can throw arbitrary Linux distros in various forms at
> QEMU, and it will catch and run them. For me, already this is more usable.
Yes, I completely agree that this is an unfortunate limitation in the
KVM tool. We definitely nee
Hi Avi,
On Sun, Nov 6, 2011 at 5:56 PM, Avi Kivity wrote:
> On 11/06/2011 03:06 PM, Pekka Enberg wrote:
>> On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
>> > You say that kvm-tool's scope is broader than Alex's script, therefore
>> > the latter is po
Hi Jan,
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka wrote:
> "Usable" - I've tried kvm-tool several times and still (today) fail to
> get a standard SUSE image (with a kernel I have to compile and provide
> separately...) up and running *). Likely a user mistake, but none that
> is very obvious. A
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
> Alex's script, though, is just a few dozen lines. kvm-tool is a 20K
> patch - in fact 2X as large as kvm when it was first merged. And it's
> main feature seems to be that "it is not qemu".
I think I've mentioned many times that I find the QEM
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity wrote:
> You say that kvm-tool's scope is broader than Alex's script, therefore
> the latter is pointless.
I'm saying that Alex's script is pointless because it's not attempting
to fix the real issues. For example, we're trying to make make it as
easy as
On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity wrote:
> But from your description, you're trying to solve just another narrow
> problem:
>
> "The end game for me is to replace QEMU/VirtualBox for Linux on Linux
> virtualization for my day to day purposes. "
>
> We rarely merge a subsystem to solve one
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity wrote:
> So far, kvm-tool capabilities are a subset of qemu's. Does it add
> anything beyond a different command-line?
I think "different command line" is a big thing which is why we've
spent so much time on it. But if you mean other end user features,
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity wrote:
>> People seem to think the KVM tool is only about solving a specific
>> problem to kernel developers. That's certainly never been my goal as I
>> do lots of userspace programming as well. The end game for me is to
>> replace QEMU/VirtualBox for Li
Hi Avi,
On Sun, 2011-11-06 at 12:23 +0200, Avi Kivity wrote:
> > If this is a serious attempt in making QEMU command line suck less on
> > Linux, I think it makes sense to do this properly instead of adding a
> > niche script to the kernel tree that's simply going to bit rot over
> > time.
>
> Yo
On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity wrote:
>> I'm happy to see some real competition for the KVM tool in usability. ;-)
>>
>> That said, while the script looks really useful for developers,
>> wouldn't it make more sense to put it in QEMU to make sure it's kept
>> up-to-date and distributi
Hi Alexander,
On Sun, Nov 6, 2011 at 3:35 AM, Alexander Graf wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel t
On Wed, Aug 24, 2011 at 1:16 AM, Alexander Graf wrote:
> On LinuxCon I had a nice chat with Linus on what he thinks kvm-tool
> would be doing and what he expects from it. Basically he wants a
> small and simple tool he and other developers can run to try out and
> see if the kernel they just built
59 matches
Mail list logo
