Some recent change made PPC guests always start at address 0x0 because env
isn't synced to kvm_state on first bootup.
I'm not sure if this is the correct bugfix, but at least it makes PPC boot
again with KVM enabled.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/ppc_newworld.c |4
While x86 only needs to sync cr0-4 to know all about its MMU state and enable
qemu to resolve virtual to physical addresses, we need to sync all of the
segment registers on PPC to know which mapping we're in.
So let's grab the segment register contents to be able to use the x monitor
command and
On Mon, Nov 23, 2009 at 09:39:52PM +0200, Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 07:48:20PM +0100, Sebastian Herbszt wrote:
What about using the vendor provided by CPUID, so it displays the correct
value on coreboot and others, and
change qemu cpus to a different vendor string like
Hi,
Qemu creates a bunch of default devices (serial, parallel, vga, ...) if
the user didn't specify one on the command line. Unfortunaly this
doesn't work well with the qdev way of doing things because this logic
is tied to the -serial, -parallel, ... command line switches. Devices
created
Make the 'vc' chardev backend print a title line with the chardev name
after initialization, using CharDriverState-label.
This replaces the banner printing code in vl.c.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
console.c |8
vl.c | 24
2
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
console.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/console.c b/console.c
index 2aeb5b3..8086bd6 100644
--- a/console.c
+++ b/console.c
@@ -1388,8 +1388,10 @@ static void text_console_do_init(CharDriverState *chr,
Qemu creates a default serial line for you in case you didn't specify
one on the command line. Right now this is tied to the '-serial
chardev' command line switch, which in turn causes trouble if you are
creating your serial line via '-device isa-serial,props'.
This patch adds a variable
Add global command line option to disable default devices.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
qemu-options.hx |5 +
vl.c|6 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index b65fd74..70929fa
The logic in this code obviously predates the multiple monitor
capability of qemu and looks increasingly silly these days.
I think the intention of this piece of code is to get a reasonable
default for the -nographic case: have monitor and serial line muxed
on stdio.
With the new default_serial
Qemu creates a vga display for you in case you didn't specify one on the
command line. Right now this is tied to the '-vga type' command line
switch, which in turn causes trouble if you are creating your gfx card
using '-device VGA,props'.
This patch adds a variable default_vga which says
This patch makes the monitor default device configuration work like the
default serial and parallel port devices. It adds a variable
default_monitor which says whenever a default monitor should be added.
It is enabled by default. It is cleared when qemu finds '-monitor' on
the command line.
Qemu creates a default parallel port for you in case you didn't specify
one on the command line. Right now this is tied to the '-parallel
chardev' command line switch, which in turn causes trouble if you are
creating your parallel port via '-device isa-parallel,props'.
This patch adds a variable
Add a default_drive variable which specified whenever the default drives
(cdrom, floppy, sd) should be created. It is cleared when the new
-nodefaults switch is specified on the command line.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
vl.c | 16 ++--
1 files changed, 10
Add a default_net variable which specified whenever a default network
should be created. It is cleared in case any -net option is specified
and it is also added to the new -nodefaults switch.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
net.c |5 -
net.h |1 +
vl.c |1 +
vnet_hdr is initialized at 1 by default. We need to reset it to 0 if
the kernel doesn't support IFF_VNET_HDR.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
net/tap-linux.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/tap-linux.c b/net/tap-linux.c
index
Replace defconfing - defconfig
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 7843690..63a7128 100644
--- a/Makefile
+++ b/Makefile
@@ -45,7 +45,7 @@ config-all-devices.mak:
Gerd Hoffmann kra...@redhat.com writes:
Hi,
Qemu creates a bunch of default devices (serial, parallel, vga, ...) if
the user didn't specify one on the command line. Unfortunaly this
doesn't work well with the qdev way of doing things because this logic
is tied to the -serial, -parallel,
Hi Pierre,
On Tue, 2009-11-24 at 10:06 +0100, Pierre Riteau wrote:
vnet_hdr is initialized at 1 by default. We need to reset it to 0 if
the kernel doesn't support IFF_VNET_HDR.
Thanks for the patch, but I'd prefer us to make sure we catch all cases.
Does this work for you?
Thanks,
Mark.
On Tue, 2009-11-24 at 10:06 +0100, Pierre Riteau wrote:
vnet_hdr is initialized at 1 by default. We need to reset it to 0 if
the kernel doesn't support IFF_VNET_HDR.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
Thanks Pierre, I see why this is needed now
Acked-by: Mark McLoughlin
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laordl...@redhat.com wrote:
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into it, ordered by complexity:
1. Control*every* feature
On Mon, Nov 23, 2009 at 06:06:23PM -0200, Luiz Capitulino wrote:
Return a QDict with server information. Connected clients are returned
as a QList of QDicts.
The new functions (vnc_qdict_remote_addr(), vnc_qdict_local_addr() and
put_addr_qdict()) are used to insert 'host' and 'service'
On 11/23/2009 08:28 PM, Anthony Liguori wrote:
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of guest visible state is buggy on
the current implementation, we can't drop entirely the possibility of
fixing it on
This patch adds infrastructure and command line option for setting
global defaults for device properties, i.e. you can for example use
-global virtio-blk-pci.vectors=0
to turn off msi by default for all virtio block devices. The config
file syntax is:
[global]
driver = virtio-blk-pci
On 24 nov. 2009, at 11:28, Mark McLoughlin wrote:
On Tue, 2009-11-24 at 10:06 +0100, Pierre Riteau wrote:
vnet_hdr is initialized at 1 by default. We need to reset it to 0 if
the kernel doesn't support IFF_VNET_HDR.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
Thanks Pierre, I see
On Tue, 2009-11-24 at 12:17 +0100, Pierre Riteau wrote:
On 24 nov. 2009, at 11:28, Mark McLoughlin wrote:
On Tue, 2009-11-24 at 10:06 +0100, Pierre Riteau wrote:
vnet_hdr is initialized at 1 by default. We need to reset it to 0 if
the kernel doesn't support IFF_VNET_HDR.
On Mon, 23 Nov 2009 14:50:05 +0100
Alexander Graf ag...@suse.de wrote:
Am 23.11.2009 um 14:34 schrieb Luiz Capitulino lcapitul...@redhat.com:
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
On 11/16/09 19:53, Paul Brook wrote:
Capping the amount of memory required for a transfer *is* implemented, in both
LSI and virtio-blk. The exception being SCSI passthrough where the kernel API
makes it impossible.
Well. Figured while doing more testing: The allowed request size is
limited
-Original Message-
From: Rabin Vincent [mailto:rabin.vinc...@gmail.com] On Behalf Of Rabin
Vincent
Hello Rabin,
I've put up the current source at http://repo.or.cz/w/qemu/avr32.git,
and a small README and some prebuilt kernel and busybox binaries to play
with at
On 24.11.2009, at 12:55, Luiz Capitulino wrote:
On Mon, 23 Nov 2009 14:50:05 +0100
Alexander Graf ag...@suse.de wrote:
Am 23.11.2009 um 14:34 schrieb Luiz Capitulino lcapitul...@redhat.com:
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Luiz
On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
Paolo Bonzini wrote:
I don't see how this fixes anything. If you used feature bits, how do
you migrate from a version that has a feature bit that an older version
doesn't know about? Do you just ignore it?
I'd go with chunk
On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
We cannot even create a new 'hack section' for new code since the
sections are ordered and expected to be exact match on the
destination.
The result is that new-old migration cannot work. This is not cross
On Mon, Nov 23, 2009 at 02:36:40PM +0200, Gleb Natapov wrote:
My problem implementing optional features/sections/... is not the
savevm/VMState bits. At the end, implementing that is easy. What is
more dificult is once that a device have 5 features, what are the valid
combinations. i.e.
But it's easy to support migration to old qemu just
by discarding the INTx state, and this is not
at all harder, or worse, than migrating from old qemu
to new one.
Do we really care about migrating to older versions?
Migrating to a new version (backward compatibility) I see the use, it
On Mon, Nov 23, 2009 at 08:49:23AM -0600, Anthony Liguori wrote:
Juan Quintela wrote:
Anthony Liguori anth...@codemonkey.ws wrote:
Juan Quintela wrote:
I'm not at all convinced that you can downgrade the version of a
device without exposing a functional change to a guest. In
Michael S. Tsirkin wrote:
On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
We cannot even create a new 'hack section' for new code since the
sections are ordered and expected to be exact match on the
destination.
The result is that new-old migration cannot work.
On Tuesday 24 November 2009, Gerd Hoffmann wrote:
On 11/16/09 19:53, Paul Brook wrote:
Capping the amount of memory required for a transfer *is* implemented, in
both LSI and virtio-blk. The exception being SCSI passthrough where the
kernel API makes it impossible.
Well. Figured while
On Tue, Nov 24, 2009 at 01:35:35PM +, Paul Brook wrote:
But it's easy to support migration to old qemu just
by discarding the INTx state, and this is not
at all harder, or worse, than migrating from old qemu
to new one.
Do we really care about migrating to older versions?
On Tue, Nov 24, 2009 at 07:45:13AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
We cannot even create a new 'hack section' for new code since the
sections are ordered and expected to be exact match on the
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than producing state that is bug-compatible with
previous versions.
It seems to me that old-new and new-old migrations are
of about the same level of difficulty.
Supporting one of these but not the other
On Mon, Nov 23, 2009 at 01:15:01PM +0100, Juan Quintela wrote:
Dor Laor dl...@redhat.com wrote:
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into it, ordered by complexity:
1. Control
On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laordl...@redhat.com wrote:
In the last couple of days we discovered some issues regarding stable
ABI and the robustness of the live migration protocol. Let's just jump
right into
On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
Anthony Liguori anth...@codemonkey.ws wrote:
Juan Quintela wrote:
Dor Laor dl...@redhat.com wrote:
My idea here is that we need to have further use of machine
descriptions, once that is done, we need something like a
On 23 nov. 2009, at 19:47, Jan Kiszka wrote:
Avi Kivity wrote:
On 11/03/2009 11:40 AM, Liran Schour wrote:
- Liran
Avi Kivitya...@redhat.com wrote on 02/11/2009 20:47:34:
On 11/02/2009 03:40 PM, lir...@il.ibm.com wrote:
This series adds support for live migration without shared
On Tue, Nov 24, 2009 at 12:06:28PM +0100, Gerd Hoffmann wrote:
This patch adds infrastructure and command line option for setting
global defaults for device properties, i.e. you can for example use
-global virtio-blk-pci.vectors=0
to turn off msi by default for all virtio block devices.
Pierre Riteau wrote:
On 23 nov. 2009, at 19:47, Jan Kiszka wrote:
Avi Kivity wrote:
On 11/03/2009 11:40 AM, Liran Schour wrote:
- Liran
Avi Kivitya...@redhat.com wrote on 02/11/2009 20:47:34:
On 11/02/2009 03:40 PM, lir...@il.ibm.com wrote:
This series adds support for live migration
Michael S. Tsirkin m...@redhat.com wrote:
But to really make it work, we need to take a list of each savevm format
change and put it here. Notice that several changes are needed:
- savevm infrastructure save functions don't know about version id
- devices don't know to behave as other
On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than producing state that is bug-compatible with
previous versions.
It seems to me that old-new and new-old migrations are
of about the
Jan Kiszka wrote:
Oh, indeed, thanks. Due to the fact that this discussion suggested that
there are still open issues, I did not even checked git.
They still need to be addressed. However, I wanted to do that work in
the tree vs. outside of the tree. With all the qmp stuff happening,
that
On Mon, Nov 23, 2009 at 09:12:15AM -0600, Anthony Liguori wrote:
Eduardo Habkost wrote:
The pvclock MSRs are an example: if the guest is not using pvclock, not
restoring the MSRs won't make any difference. Strictly speaking, not
migrating them is wrong, but the user may argue that they know it
On Mon, Nov 23, 2009 at 08:53:54AM -0600, Anthony Liguori wrote:
Eduardo Habkost wrote:
Migration needs to be conservative. There should be only two possible
outcomes: 1) a successful live migration or 2) graceful failure with the
source VM still running correctly. Silently ignoring things
Michael S. Tsirkin wrote:
It's very easy: if their guest runs fine on the old qemu,
it should be safe to migrate there.
Runs fine is a qualitative statement. There is no way for qemu to
know whether a guest runs fine or not. There is no way that we can make
that statement either. It
On Tue, Nov 24, 2009 at 03:20:47PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
But to really make it work, we need to take a list of each savevm format
change and put it here. Notice that several changes are needed:
- savevm infrastructure save functions don't
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On
On Mon, Nov 23, 2009 at 01:08:30PM +0200, Gleb Natapov wrote:
-memcpy((char *)start, CPU \0 \0 , 7);
- ((char *)start)[4] = cpu_number + '0';
+memcpy((char *)start, CPU \0QEMU\0\0, 12);
+((char *)start)[4] = cpu_number + '0';
BTW, snprintf can now be used here.
On Tue, Nov 24, 2009 at 02:38:12PM +, Jamie Lokier wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Sun, Nov 22, 2009 at
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laordl...@redhat.com wrote:
In the last couple of days we discovered some
On Mon, Nov 23, 2009 at 03:00:43PM +0200, Gleb Natapov wrote:
On Sun, Nov 22, 2009 at 06:05:02PM +0100, Sebastian Herbszt wrote:
v0.11.0-rc0-1677:
use -cpu pentium and check SMBIOS tables. DMI type 4 entry is missing.
Works with Bochs bios.
See two problems here. First one in seabios
Anthony Liguori aligu...@linux.vnet.ibm.com wrote on 24/11/2009
16:27:58:
Jan Kiszka wrote:
Oh, indeed, thanks. Due to the fact that this discussion suggested that
there are still open issues, I did not even checked git.
They still need to be addressed. However, I wanted to do that work in
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination host is Fedora 12 32-bit.
Guest is running Debian Lenny 32-bit.
Symtoms: origin finishes migration correctly, but destination prints
Hi,
After migrating a VM (still running Debian Lenny 32-bit) using text consoles
(default Debian configuration, no framebuffer I think), the VM is responsive to
keyboard input but doesn't display new characters: only the cursor moves.
Otherwise the machine seems to run fine: I can log in and
On Mon, Nov 23, 2009 at 08:30:41PM +0200, Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 07:15:55PM +0100, Sebastian Herbszt wrote:
Ok - sounds good if bios_characteristics gets proper system based values.
Kevin can you help here. I can send a patch, but I am not sure I know
everything
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 12:39:50PM +0200, Dor Laor wrote:
On 11/23/2009 02:15 PM, Juan Quintela wrote:
Dor Laordl...@redhat.com wrote:
In the last couple of days we discovered some
On Tue, Nov 24, 2009 at 08:33:11AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
It's very easy: if their guest runs fine on the old qemu,
it should be safe to migrate there.
Runs fine is a qualitative statement. There is no way for qemu to
know whether a guest runs fine or
* Pierre Riteau pierre.rit...@irisa.fr [2009-11-24 09:35]:
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination host is Fedora 12 32-bit.
Guest is running Debian Lenny 32-bit.
Pierre Riteau pierre.rit...@irisa.fr wrote:
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination host is Fedora 12 32-bit.
Guest is running Debian Lenny 32-bit.
Symtoms: origin
On Tue, Nov 24, 2009 at 10:57:02AM -0500, Kevin O'Connor wrote:
On Mon, Nov 23, 2009 at 08:30:41PM +0200, Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 07:15:55PM +0100, Sebastian Herbszt wrote:
Ok - sounds good if bios_characteristics gets proper system based values.
Kevin can you help
On 24 nov. 2009, at 17:27, Ryan Harper wrote:
* Pierre Riteau pierre.rit...@irisa.fr [2009-11-24 09:35]:
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination host is Fedora 12
On 24 nov. 2009, at 17:46, Juan Quintela wrote:
Pierre Riteau pierre.rit...@irisa.fr wrote:
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination host is Fedora 12 32-bit.
Guest is
On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than producing state that is bug-compatible with
previous versions.
On Tue, Nov 24, 2009 at 07:06:01PM +0200, Blue Swirl wrote:
On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 24, 2009 at 01:59:49PM +, Paul Brook wrote:
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than
While S390x was one of the first targets that were supported by KVM it always
lacked qemu system emulation support.
In order to change that sad fact, I figured I'd just take on the task myself,
taking kuli (http://www.ibm.com/developerworks/linux/linux390/kuli.html),
Documentation/s390/kvm.txt
Because Qemu currently requires a TCG target to exist and there are quite some
useful helpers here to lay the groundwork for out KVM target, let's create a
stub TCG emulation target for S390X CPUs.
This is required to make tcg happy. The emulation target itself won't work
though.
Signed-off-by:
On our S390x Virtio machine we don't have anywhere to display early printks
on, because we don't know about VGA or serial ports.
So instead we just forward everything to the virtio console that we created
anyways.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/virtio-console.c |7
In order to debug funny kernel breakages it's always good to have a working
gdb stub around.
While Uli's patches don't include one one, I needed one that's at least good
enough for 'bt' and some variable examinations during early bootup.
So here it is - the absolute basics to get the qemu gdb
On S390x we don't want to go through the hassle of emulating real existing
hardware, because we don't need to for running Linux.
So let's instead implement a machine that is 100% based on VirtIO which we
fortunately implement already.
This patch implements the bus that is the groundwork for such
KVM on S390x requires the virtual address space of the guest's RAM to be
within the first 256GB.
The general direction I'd like to see KVM on S390 move is that this requirement
is losened, but for now that's what we're stuck with.
So let's just hack up qemu_ram_alloc until KVM behaves nicely
In order to use the new S390x virtio bus we just introduced, we also
need a machine description that sets up the machine according to our
PV specification.
Let's add that machine description and be happy!
Signed-off-by: Alexander Graf ag...@suse.de
---
Makefile.target |2 +-
This patch adds information about who handles what when it comes to S390.
I'll gladly support anything that's related to the device emulation model and
S390 KVM parts.
Since this patchset doesn't implement S390 CPU emulation, I left that part
with a question mark. As soon as Uli's patchset gets
All normal system emulation targets in qemu I'm aware of display output
on either VGA or serial output.
Our S390x virtio machine doesn't have such kind of legacy hardware. So
instead we need to default to a virtio console.
I'm not particularly proud of this patch. It would be a lot better to
S390x was one of the first platforms that received support for KVM back in the
day. Unfortunately until now there hasn't been a qemu implementation that would
enable users to actually run guests.
So let's include support for KVM S390x in qemu!
Signed-off-by: Alexander Graf ag...@suse.de
---
This patch makes configure aware of S390 hosts and guests. When not explicitly
defined using --target-list= no S390 targets will be built though.
Signed-off-by: Alexander Graf ag...@suse.de
---
configure | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git
Let's enable the basics for system emulation so we can run virtual machines
with KVM!
Signed-off-by: Alexander Graf ag...@suse.de
---
target-s390x/cpu.h| 153 -
target-s390x/exec.h |5 +
target-s390x/helper.c |
The default bootloader on S390 is zipl. Because we don't emulate normal S390
hardware we need to write our own parser for the bootloader configuration,
so we can boot off real hard disks.
This patch adds a pretty simple implementation of such an interpreter. It only
supports 512 bytes sector
Qemu won't let us run a KVM target without having host TCG support. Well, for
now we don't have any so let's implement a fake target that only stubs out
everything.
I tried to keep the patch as close to Uli's source as possible, so whenever
he feels like it he can easily diff his version against
On 11/24/2009 03:30 PM, Juan Quintela wrote:
No, new - old is way, way more difficult.
New-old is way more difficult with the current migration file format.
The current migration file format is not at all designed to be read by
an older version.
Or for that matter a tool that only cares
On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
The external version translator tool could support arbitrary
conversion between the whole NxN matrix of versions (including distro
hacks), or just those that RHEL happens to use. The tool would not be
limited to QEMU development
On Tue, Nov 24, 2009 at 06:59:01PM +0200, Gleb Natapov wrote:
On Tue, Nov 24, 2009 at 10:57:02AM -0500, Kevin O'Connor wrote:
On Mon, Nov 23, 2009 at 08:30:41PM +0200, Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 07:15:55PM +0100, Sebastian Herbszt wrote:
Ok - sounds good if
Alexander Graf wrote:
While x86 only needs to sync cr0-4 to know all about its MMU state and enable
qemu to resolve virtual to physical addresses, we need to sync all of the
segment registers on PPC to know which mapping we're in.
So let's grab the segment register contents to be able to use
On 24.11.2009, at 19:01, Jan Kiszka wrote:
Alexander Graf wrote:
While x86 only needs to sync cr0-4 to know all about its MMU state and enable
qemu to resolve virtual to physical addresses, we need to sync all of the
segment registers on PPC to know which mapping we're in.
So let's grab
Alexander Graf wrote:
On 24.11.2009, at 19:01, Jan Kiszka wrote:
Alexander Graf wrote:
While x86 only needs to sync cr0-4 to know all about its MMU state and
enable
qemu to resolve virtual to physical addresses, we need to sync all of the
segment registers on PPC to know which mapping
On 24.11.2009, at 19:12, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:01, Jan Kiszka wrote:
Alexander Graf wrote:
While x86 only needs to sync cr0-4 to know all about its MMU state and
enable
qemu to resolve virtual to physical addresses, we need to sync all of the
Alexander Graf wrote:
On 24.11.2009, at 19:12, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:01, Jan Kiszka wrote:
Alexander Graf wrote:
While x86 only needs to sync cr0-4 to know all about its MMU state and
enable
qemu to resolve virtual to physical addresses, we need to
On Tue, Nov 24, 2009 at 12:53:00PM -0500, Kevin O'Connor wrote:
On Tue, Nov 24, 2009 at 06:59:01PM +0200, Gleb Natapov wrote:
On Tue, Nov 24, 2009 at 10:57:02AM -0500, Kevin O'Connor wrote:
On Mon, Nov 23, 2009 at 08:30:41PM +0200, Gleb Natapov wrote:
On Mon, Nov 23, 2009 at 07:15:55PM
On 24.11.2009, at 19:33, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:12, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:01, Jan Kiszka wrote:
Alexander Graf wrote:
While x86 only needs to sync cr0-4 to know all about its MMU state and
enable
qemu to
Alexander Graf wrote:
On 24.11.2009, at 19:33, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:12, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:01, Jan Kiszka wrote:
Alexander Graf wrote:
While x86 only needs to sync cr0-4 to know all about its MMU state and
Paolo Bonzini wrote:
On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
The external version translator tool could support arbitrary
conversion between the whole NxN matrix of versions (including
distro
hacks), or just those that RHEL happens to use. The tool would
not be
limited to
On 24.11.2009, at 19:49, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:33, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:12, Jan Kiszka wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:01, Jan Kiszka wrote:
Alexander Graf wrote:
While x86 only needs
Alexander Graf wrote:
The default bootloader on S390 is zipl. Because we don't emulate normal S390
hardware we need to write our own parser for the bootloader configuration,
so we can boot off real hard disks.
This patch adds a pretty simple implementation of such an interpreter. It only
Alexander Graf wrote:
On our S390x Virtio machine we don't have anywhere to display early printks
on, because we don't know about VGA or serial ports.
So instead we just forward everything to the virtio console that we created
anyways.
What is this used for?
Signed-off-by: Alexander Graf
On 24.11.2009, at 19:53, Anthony Liguori wrote:
Alexander Graf wrote:
The default bootloader on S390 is zipl. Because we don't emulate normal S390
hardware we need to write our own parser for the bootloader configuration,
so we can boot off real hard disks.
This patch adds a pretty simple
1 - 100 of 139 matches
Mail list logo
