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
Hi Alexander,
On Sun, Nov 6, 2011 at 3:35 AM, Alexander Graf ag...@suse.de 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
On Sun, Nov 6, 2011 at 12:07 PM, Avi Kivity a...@redhat.com 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
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.
You
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com 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
On Sun, Nov 6, 2011 at 1:50 PM, Avi Kivity a...@redhat.com 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
On Sun, Nov 6, 2011 at 2:27 PM, Avi Kivity a...@redhat.com 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
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com 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
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com 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
Hi Jan,
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de 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
Hi Avi,
On Sun, Nov 6, 2011 at 5:56 PM, Avi Kivity a...@redhat.com wrote:
On 11/06/2011 03:06 PM, Pekka Enberg wrote:
On Sun, Nov 6, 2011 at 2:43 PM, Avi Kivity a...@redhat.com wrote:
You say that kvm-tool's scope is broader than Alex's script, therefore
the latter is pointless.
I'm
On Sun, Nov 6, 2011 at 6:19 PM, Jan Kiszka jan.kis...@web.de 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.
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 a
On Sun, Nov 6, 2011 at 7:15 PM, Alexander Graf ag...@suse.de 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
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]
On Sun, Nov 6, 2011 at 7:30 PM, Alexander Graf ag...@suse.de 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
On Sun, Nov 6, 2011 at 7:08 PM, Anthony Liguori anth...@codemonkey.ws 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
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:31 PM,
On Sun, Nov 6, 2011 at 8:54 PM, Pekka Enberg penb...@kernel.org 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?
Ted, I'm confused
On Sun, Nov 6, 2011 at 9:11 PM, Paolo Bonzini pbonz...@redhat.com 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
On Sun, Nov 6, 2011 at 9:14 PM, Paolo Bonzini pbonz...@redhat.com 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
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini pbonz...@redhat.com 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
On Sun, Nov 6, 2011 at 10:01 PM, Paolo Bonzini pbonz...@redhat.com 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
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,
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.
On Mon, Nov 7, 2011 at 12:08 AM, Frank Ch. Eigler f...@redhat.com 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
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@redhat.com 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
On Mon, Nov 7, 2011 at 10:00 AM, Paolo Bonzini pbonz...@redhat.com 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
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 fact
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 specs. It's
_the_ single worst way to write software
On Mon, Nov 7, 2011 at 12:11 PM, Gerd Hoffmann kra...@redhat.com 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
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, 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
On Mon, Nov 7, 2011 at 1:02 PM, Paolo Bonzini pbonz...@redhat.com 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
On Mon, Nov 7, 2011 at 2:18 PM, Gerd Hoffmann kra...@redhat.com 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.
Hi Avi,
On Mon, Nov 7, 2011 at 2:26 PM, Avi Kivity a...@redhat.com 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
Hi Ted,
On Mon, Nov 7, 2011 at 2:29 PM, Ted Ts'o ty...@mit.edu 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
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu 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
On Mon, Nov 7, 2011 at 2:47 PM, Ted Ts'o ty...@mit.edu 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
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 vi...@deater.net wrote:
Never overtly. They're too clever for that.
If you want me to take you seriously, spare me from the conspiracy
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
Hi Ted,
On Mon, Nov 7, 2011 at 10:32 PM, Ted Ts'o ty...@mit.edu 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
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
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;
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
On Tue, Nov 8, 2011 at 3:29 PM, Karel Zak k...@redhat.com 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
On Tue, Nov 8, 2011 at 4:52 PM, Christoph Hellwig h...@infradead.org 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.
On Wed, Aug 24, 2011 at 1:16 AM, Alexander Graf ag...@suse.de 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
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-{
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
e run something
more complicated than what I'm using for testing.
Signed-off-by: Pekka Enberg <penb...@iki.fi>
---
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
+++
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: Make
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 <penb...@iki.fi>
---
hw/arm/raspi.c | 31 +--
1 file c
On 02/15/2018 01:48 PM, Peter Maydell wrote:
On 8 February 2018 at 05:50, Pekka Enberg <penb...@iki.fi> 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-
Hi,
On 02/15/2018 02:39 PM, Peter Maydell wrote:
On 8 February 2018 at 05:50, Pekka Enberg <penb...@iki.fi> 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 mach
e run something
more complicated than what I'm using for testing.
Signed-off-by: Pekka Enberg <penb...@iki.fi>
---
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
+++
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 <penb...@iki.fi>
---
hw/arm/raspi.c | 31 +--
1 file 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 <penb...@iki.fi>
---
hw/arm/bcm2836.c | 17 +
hw/arm/raspi.c | 3
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
59 matches
Mail list logo
