On 25.11.2009, at 00:05, H. Peter Anvin wrote:
> On 11/23/2009 12:11 PM, H. Peter Anvin wrote:
>> On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
>>>
>>> All not needed. Simply registering as qdev device is enougth. You can
>>> then add a debug port like this, without adding new cmd line options
Gleb Natapov wrote:
> > But QEMU is used to run old OSes too.
> >
> That's OK. I don't expect BIOS to be reloaded if OS restart by jumping
> to BIOS reset code.
That's good then.
What about DOS and DOS-extender programs which do a soft reset by
triple-faulting the CPU (see Sebastian's notes on i
This patch extends the qemu-kvm state sync logic with support for
KVM_GET/SET_VCPU_EVENTS, giving access to yet missing exception,
interrupt and NMI states.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 11 +++
kvm.h |1 +
target-i386/cpu.h |5 +++
targe
Signed-off-by: Jan Kiszka
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index d6bc23a..89fd7a5 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -717,12 +717,8 @@ int kvm_arch_put_registers(CPUState *env)
ret = kvm_put_mp_state(env);
if (ret < 0)
return ret;
-
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 Tue, Nov 24, 2009 at 7:51 PM, wrote:
>
> I am working on a project that extends qemu to track the memory accesses.
> All the functions in target-i386/ops_mem.h are instrumented.
> Logging the reads work fine, the writes give are troublesome.
> The code that I am tracking contains a lot of xor
On 11/23/2009 12:11 PM, H. Peter Anvin wrote:
> On 11/23/2009 02:52 AM, Gerd Hoffmann wrote:
>>
>> All not needed. Simply registering as qdev device is enougth. You can
>> then add a debug port like this, without adding new cmd line options:
>>
>>-chardev vc,id=debug -device isa-debugcon,cha
Hi Liran,
trying to understand the code and fixing some cosmetic issues around
progress reporting, one potentially performance-relevant question popped up:
lir...@il.ibm.com wrote:
> diff --git a/block-migration.c b/block-migration.c
> new file mode 100644
> index 000..4b4eddf
> --- /dev/null
> > Can't you just use kboot?
> >
> > Use a kernel loader to load the kboot module/initrd, include kboot as our
> > firmware, then let kboot do the magic to launch the real linux kernel
> > from disk.
>
> Hm, so we'd have to rely on kexec working properly? I've seen how badly
> that turned out on
Hello everybody,
I am working on a project that extends qemu to track the memory accesses.
All the functions in target-i386/ops_mem.h are instrumented.
Logging the reads work fine, the writes give are troublesome.
The code that I am tracking contains a lot of xor instructions.
I have tracked the
Hi,
I am seeing funny QEMU behaviour when using "-net socket,listen"
mechanism.
When connecting and disconnecting several clients I start
to get duplicated packets from QEMU server.
IMHO, the following is happenning:
1. Client is disconnected: we get into net_socket_send callback.
2. net_socket_
On Tue, Nov 24, 2009 at 03:57:48PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> It's useful because this way I won't have to maintain the fix, and it
>> will make it possible for guests to experiment with layouts, without
>> hacking qemu. If someone wants to make it a product, that'
Michael S. Tsirkin wrote:
It's useful because this way I won't have to maintain the fix, and it
will make it possible for guests to experiment with layouts, without
hacking qemu. If someone wants to make it a product, that's a different
thing.
Advertising a new feature is not hard. It's one
msix state is managed by OS, not the
driver, so it's wrong to touch it
on io from driver
Signed-off-by: Michael S. Tsirkin
---
hw/virtio-pci.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index aebcf9d..d222ce0 100644
--- a
will be used by virtio on soft reset
Signed-off-by: Michael S. Tsirkin
---
hw/msix.c |7 +++
hw/msix.h |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/msix.c b/hw/msix.c
index 548ffd5..d499441 100644
--- a/hw/msix.c
+++ b/hw/msix.c
@@ -378,3 +378,10 @@ void m
This two patch series fixes MSI-X reset
issue detected with windows guests
Michael S. Tsirkin (2):
msix: add helper to mark all msix entries
virtio: do not reset msix state on soft reset
hw/msix.c |7 +++
hw/msix.h |1 +
hw/virtio-pci.c | 12
3 files ch
On Tue, Nov 24, 2009 at 03:04:47PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Tue, Nov 24, 2009 at 01:50:25PM -0600, Anthony Liguori wrote:
>>
>>> Michael S. Tsirkin wrote:
>>>
virtio net currently assumes that the first s/g element it gets is
always virtio ne
On 24 nov. 2009, at 12:22, Mark McLoughlin wrote:
> 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
Hi Mark!
Mark Williamson wrote:
Way back in the mists of time (uh, something like that 2004-05) I had some
discussions with some of the S390 people about using kboot for more flexible
boot, since it tallied with their interests. Although at that point I had the
impression that zipl was restri
Michael S. Tsirkin wrote:
On Tue, Nov 24, 2009 at 01:50:25PM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
virtio net currently assumes that the first s/g element it gets is
always virtio net header. This is wrong.
There should be no assumption on sg boundaries. For example,
On Tue, Nov 24, 2009 at 08:41:47PM +0200, Gleb Natapov wrote:
> On Tue, Nov 24, 2009 at 12:53:00PM -0500, Kevin O'Connor wrote:
> > However, I'm not really sure how the above overlaps with your SVVP
> > patch..
> >
> It is not. I am just thinking about putting real info there instead of
> "not sup
On Tue, Nov 24, 2009 at 01:29:09PM -0600, Anthony Liguori wrote:
> Paolo Bonzini wrote:
>> On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
>>
>> Since my brain is not working well today, I'll just point out that of
>> course I meant
On 24.11.2009, at 20:48, Anthony Liguori wrote:
> Alexander Graf wrote:
>>> Oh, that's bad :-)
>>>
>>> That should really be it's own character device. We don't really have a
>>> way to connect two character devices like that. Maybe muxing?
>>>
>>
>> So you want me to implement char muxi
On Tue, Nov 24, 2009 at 01:50:25PM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> virtio net currently assumes that the first s/g element it gets is
>> always virtio net header. This is wrong.
>> There should be no assumption on sg boundaries. For example, the guest
>> should be able
Michael S. Tsirkin wrote:
virtio net currently assumes that the first s/g element it gets is
always virtio net header. This is wrong.
There should be no assumption on sg boundaries. For example, the guest
should be able to put the virtio_net_hdr in the front of the skbuf data
if there is room.
Alexander Graf wrote:
Oh, that's bad :-)
That should really be it's own character device. We don't really have a way to connect two character devices like that.
Maybe muxing?
So you want me to implement char muxing and a bootloader within a week? :)
Char muxing is already there.
virtio net currently assumes that the first s/g element it gets is
always virtio net header. This is wrong.
There should be no assumption on sg boundaries. For example, the guest
should be able to put the virtio_net_hdr in the front of the skbuf data
if there is room. Get rid of this assumption,
On 24.11.2009, at 20:30, Anthony Liguori wrote:
> Alexander Graf wrote:
>> On 24.11.2009, at 20:25, Anthony Liguori wrote:
>>
>>
>>> Alexander Graf wrote:
>>>
On 24.11.2009, at 19:55, Anthony Liguori wrote:
> Alexander Graf wrote:
>
>> On our S
Alexander Graf wrote:
On 24.11.2009, at 20:25, Anthony Liguori wrote:
Alexander Graf wrote:
On 24.11.2009, at 19:55, Anthony Liguori wrote:
Alexander Graf wrote:
On our S390x Virtio machine we don't have anywhere to display early printks
on, because we don't kn
On 24.11.2009, at 20:26, Anthony Liguori wrote:
> Alexander Graf wrote:
>> 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 pars
Paolo Bonzini wrote:
On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
Since my brain is not working well today, I'll just point out that of
course I meant "the primary representation of _schemas_ an XML
document" or anything like that
On 24.11.2009, at 20:25, Anthony Liguori wrote:
> Alexander Graf wrote:
>> On 24.11.2009, at 19:55, Anthony Liguori wrote:
>>
>>
>>> 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
Alexander Graf wrote:
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
Alexander Graf wrote:
On 24.11.2009, at 19:55, Anthony Liguori wrote:
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
Blue Swirl wrote:
But the complexity would be a problem only for the transformation
matrix project. For QEMU the gain would be simplified design, maybe at
the expense of some CPP magic.
I don't think it's always a matter of just transforming state. There
will be certain features that need
On 24.11.2009, at 20:03, Jan Kiszka wrote:
> Alexander Graf wrote:
>> 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:
>>
>>> Alexan
Alexander Graf wrote:
> 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 Kiszk
On 11/24/2009 07:51 PM, Anthony Liguori wrote:
to make the primary representation of state an XML document
Since my brain is not working well today, I'll just point out that of
course I meant "the primary representation of _schemas_ an XML document"
or anything like that.
or anything like
On 24.11.2009, at 19:55, Anthony Liguori wrote:
> 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
>> anyw
On Tue, Nov 24, 2009 at 8:51 PM, Anthony Liguori wrote:
> 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
> hac
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 pre
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
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
support
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:
>>
>>> Alexan
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
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
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 stat
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:
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 ph
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 sy
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 wh
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 le
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
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 bios
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 enviro
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
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 t
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 sizes
Let's enable the basics for system emulation so we can run virtual machines
with KVM!
Signed-off-by: Alexander Graf
---
target-s390x/cpu.h| 153 -
target-s390x/exec.h |5 +
target-s390x/helper.c | 22 +
targ
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
---
configure | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/configure b/c
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
---
configure
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
ha
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 co
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
---
Makefile.target |2 +-
hw/s390-virtio.c | 243
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 :-).
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
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 stu
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
---
hw/virtio-console.c |7 +++
hw/virtio-c
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: A
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 and
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 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 produc
On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin 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 24 nov. 2009, at 17:46, Juan Quintela wrote:
> Pierre Riteau 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 Debia
On 24 nov. 2009, at 17:27, Ryan Harper wrote:
> * Pierre Riteau [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
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
Pierre Riteau 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 finishes migration co
* Pierre Riteau [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.
> Symtoms: origin finish
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 ru
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" 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 Laor wrote:
> > In the last couple of days we discovered some issues regardi
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
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 see
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
"Anthony Liguori" 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
> the tree vs. out
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 s
On Tue, Nov 24, 2009 at 03:21:34PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" 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 Laor wrote:
> > In the last couple of days we discovered some issues regardi
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,
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, snprint
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 N
On Tue, Nov 24, 2009 at 03:20:47PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" 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
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 h
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 igno
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 k
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 s
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
> >
"Michael S. Tsirkin" 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 Laor wrote:
> In the last couple of days we discovered some issues regarding stable
> ABI and the robustness of the live migration protocol.
"Michael S. Tsirkin" 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 version
>>
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 Kivity wrote on 02/11/2009 20:47:34:
> On 11/02/2009 03:40 PM, lir...@il.ibm.com wrote:
>
>> This series adds supp
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 devi
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 Kivity 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
On Mon, Nov 23, 2009 at 03:13:59PM +0100, Juan Quintela wrote:
> Anthony Liguori wrote:
> > Juan Quintela wrote:
> >> Dor Laor wrote:
> >>>
> >>
> >> My idea here is that we need to have further use of machine
> >> descriptions, once that is done, we need something like a new property
> >> f
1 - 100 of 143 matches
Mail list logo
