Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 09:28:34AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut
We should just qemu_ram_alloc() that memory regardless of whether we
every map it into the guest. Since roms can be large, we want to send
their contents over during the live part of migration. If we use
qemu_ram_alloc(), we get that for free.
Currently live migration uses ram_addrs,
On 12/22/2009 03:04 PM, Paul Brook wrote:
We should just qemu_ram_alloc() that memory regardless of whether we
every map it into the guest. Since roms can be large, we want to send
their contents over during the live part of migration. If we use
qemu_ram_alloc(), we get that for free.
On 12/22/2009 07:04 AM, Paul Brook wrote:
We should just qemu_ram_alloc() that memory regardless of whether we
every map it into the guest. Since roms can be large, we want to send
their contents over during the live part of migration. If we use
qemu_ram_alloc(), we get that for free.
Ram allocations should be associated with a device. The VMState stuff
this should make this fairly straightforward.
Right, but for the sake of simplicity, you don't want to treat that ram
any differently than main ram wrt live migration. That's why I proposed
adding a context id for each
On 12/22/2009 09:54 AM, Paul Brook wrote:
Ram allocations should be associated with a device. The VMState stuff
this should make this fairly straightforward.
Right, but for the sake of simplicity, you don't want to treat that ram
any differently than main ram wrt live migration. That's
On Mon, Dec 21, 2009 at 10:40:56AM -0600, Anthony Liguori wrote:
On 12/21/2009 01:32 AM, Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote:
On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
I think we have two ways to view firmware. The first
On 12/21/2009 10:43 AM, Gleb Natapov wrote:
There are some really ugly corner cases here. For instance, guest
is running and the user does a yum update which upgrades the qemu
package. This includes laying down a new bios.
User eventually restarts guest, now we re-read BIOS and we're on a
On Mon, Dec 21, 2009 at 09:40:47AM +0200, Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
just arguing if the same applies for the case that migration was done
between boot and reset.
On Mon, Dec 21, 2009 at 11:26:12AM -0600, Anthony Liguori wrote:
On 12/21/2009 10:43 AM, Gleb Natapov wrote:
There are some really ugly corner cases here. For instance, guest
is running and the user does a yum update which upgrades the qemu
package. This includes laying down a new bios.
On 12/21/2009 11:43 AM, Gleb Natapov wrote:
Why I will never have reset equivalent to power off + startup? Are you
saying we are not capable of implementing spec correctly?
No, I'm saying that if you want reset absolutely equivalent to power off
+ startup, then you need to fork() and
On Mon, Dec 21, 2009 at 01:13:10PM -0600, Anthony Liguori wrote:
On 12/21/2009 11:43 AM, Gleb Natapov wrote:
Why I will never have reset equivalent to power off + startup? Are you
saying we are not capable of implementing spec correctly?
No, I'm saying that if you want reset absolutely
On 12/21/2009 01:43 PM, Gleb Natapov wrote:
Please stop thinking so :) Especially about user driven upgrades.
Why combine disadvantages of vitalization with pain of physical HW
management? Or may be next step will be to require uploading of CPU
microcode to take advantage of KVM/tcg bug fixes?
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I consider ready
for merging. Changes:
* pci roms: will be loaded via option pci rom bar.
* non-pci roms: will be
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I consider ready
for merging. Changes:
* pci roms: will be loaded via option pci rom bar.
* non-pci
On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I consider ready
for merging. Changes:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:43:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Fri, Dec 18, 2009 at 12:01:06PM +0100, Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut down and start up again. That's
the right semantics IMHO.
Reset is equivalent (or should be) to shut down and start up again.
Not at all. Reset can happen in a
On 12/20/2009 05:11 PM, Anthony Liguori wrote:
Not at all. Reset can happen in a lot of different ways, some that
there is really no way to detect (jumping right to BIOS vector). From
a hardware perspective, powering down a CPU and powering it on again
behaves very differently than reset
On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut down and start up again. That's
the right semantics IMHO.
Reset is equivalent (or should be) to shut down
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut down and start up again. That's
the right semantics IMHO.
Reset
Avi Kivity wrote:
We should just qemu_ram_alloc() that memory regardless of whether we
every map it into the guest. Since roms can be large, we want to
send their contents over during the live part of migration. If we
use qemu_ram_alloc(), we get that for free.
Currently live migration
On Sun, Dec 20, 2009 at 09:28:34AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 09:11:18AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
On Sun, Dec 20, 2009 at 08:58:40AM -0600, Anthony Liguori wrote:
No. You have to physically shut down and start up again.
On 12/20/2009 05:31 PM, Anthony Liguori wrote:
Avi Kivity wrote:
We should just qemu_ram_alloc() that memory regardless of whether we
every map it into the guest. Since roms can be large, we want to
send their contents over during the live part of migration. If we
use qemu_ram_alloc(), we
On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
More importantly though, what's the use-case here?
Use-case for what? This just what need to be done for correct HW
emulation.
Live migration is transparent to the guest. The fact that firmware
can
On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
More importantly though, what's the use-case here?
Use-case for what? This just what need to be done for correct HW
emulation.
Live
On Sun, Dec 20, 2009 at 04:08:32PM +, Blue Swirl wrote:
On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
More importantly though, what's the use-case here?
Use-case for what?
2009/12/20 Gleb Natapov g...@redhat.com:
On Sun, Dec 20, 2009 at 04:08:32PM +, Blue Swirl wrote:
On Sun, Dec 20, 2009 at 3:52 PM, Gleb Natapov g...@redhat.com wrote:
On Sun, Dec 20, 2009 at 09:39:38AM -0600, Anthony Liguori wrote:
Gleb Natapov wrote:
More importantly though, what's the
Gleb Natapov wrote:
It's not a matter of correctness IMHO.
Ah now I see what you mean. New FW has to be used after reboot because old
one may not be able to init HW any longer.
I think we have two ways to view firmware. The first would be to treat
guest firmware as part of the guest.
On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
I think we have two ways to view firmware. The first would be to treat
guest firmware as part of the guest. What that means it that we should
store all firmware in an nvram file, migrate the nvram file during
migration
On Sun, Dec 20, 2009 at 08:59:48PM -0500, Kevin O'Connor wrote:
On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
I think we have two ways to view firmware. The first would be to treat
guest firmware as part of the guest. What that means it that we should
store all
On Sun, Dec 20, 2009 at 11:48:20AM -0600, Anthony Liguori wrote:
system_reset _is_ hard shutdown/start-up. If it is not it is a bug, we
just arguing if the same applies for the case that migration was done
between boot and reset.
It's not and it will never be completely.
There are always
Gerd Hoffmann wrote:
From: Anthony Liguori aligu...@us.ibm.com
Hi,
Option rom saga continued. This is the first series I consider ready
for merging. Changes:
* pci roms: will be loaded via option pci rom bar.
* non-pci roms: will be loaded via fw_cfg.
Note that using the old
On 12/18/09 15:35, Anthony Liguori wrote:
I know this series carries a good bit of risk but I'd like to bring it
in 0.12.0. Because this has a guest visible change to the PCI devices,
we cannot carry it in stable-0.12 post release and I think the
functionality it brings it's very important.
Gerd Hoffmann wrote:
On 12/18/09 15:35, Anthony Liguori wrote:
I know this series carries a good bit of risk but I'd like to bring it
in 0.12.0. Because this has a guest visible change to the PCI devices,
we cannot carry it in stable-0.12 post release and I think the
functionality it brings
On 12/18/09 17:42, Anthony Liguori wrote:
Do we need to do something for -M pc-0.11? Like loading the pci roms
via fw_cfg too so the guest doesn't see the new pci rom bar?
Yes, we do. We can fix that problem as a stable-0.12 update though.
Right now, migration with pc-0.11 is broken in other
Gerd Hoffmann wrote:
On 12/18/09 17:42, Anthony Liguori wrote:
Do we need to do something for -M pc-0.11? Like loading the pci roms
via fw_cfg too so the guest doesn't see the new pci rom bar?
Yes, we do. We can fix that problem as a stable-0.12 update though.
Right now, migration with
Gerd Hoffmann wrote:
Is 0.11 - 0.12 migration supposed to work? That could become quite
nasty too. But maybe that is impossible anyway due to the switch to
seabios?
In theory, it should work. SeaBIOS should not be a guest visible change
because the guest should not depend on what BIOS we're
On 12/18/09 18:14, Anthony Liguori wrote:
If you've got additional changes, please send them out, otherwise, let
me know if you're happy with what's in staging.
Looks good.
cheers,
Gerd
Sebastian Herbszt wrote:
Gerd Hoffmann wrote:
On 12/18/09 17:42, Anthony Liguori wrote:
Do we need to do something for -M pc-0.11? Like loading the pci roms
via fw_cfg too so the guest doesn't see the new pci rom bar?
Yes, we do. We can fix that problem as a stable-0.12 update though.
Right
Anthony Liguori wrote:
Sebastian Herbszt wrote:
Gerd Hoffmann wrote:
On 12/18/09 17:42, Anthony Liguori wrote:
Do we need to do something for -M pc-0.11? Like loading the pci roms
via fw_cfg too so the guest doesn't see the new pci rom bar?
Yes, we do. We can fix that problem as a
Gerd Hoffmann wrote:
On 12/18/09 17:42, Anthony Liguori wrote:
Do we need to do something for -M pc-0.11? Like loading the pci roms
via fw_cfg too so the guest doesn't see the new pci rom bar?
Yes, we do. We can fix that problem as a stable-0.12 update though.
Right now, migration with
On Fri, Dec 18, 2009 at 11:12:06AM -0600, Anthony Liguori wrote:
BTW, the following works:
sudo x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img -snapshot
-m 512 -net nic,model=rtl8139,macaddr=56:54:32:12:34:56 -net
nic,model=e1000,macaddr=56:54:32:12:34:57 -net
Kevin O'Connor wrote:
On Fri, Dec 18, 2009 at 11:12:06AM -0600, Anthony Liguori wrote:
BTW, the following works:
sudo x86_64-softmmu/qemu-system-x86_64 -hda ~/images/linux.img -snapshot
-m 512 -net nic,model=rtl8139,macaddr=56:54:32:12:34:56 -net
45 matches
Mail list logo
