On 11/29/2009 04:17 PM, Andreas Färber wrote:
This problem is still around after Juan's Makefile reorganizations.
Before, I had provided two alternative patches:
* The first version wrote the list of libqemu_common.a's and
$(HWLIB)'s object files into a text file from Makefile[.hw] that was
On Sun, Nov 29, 2009 at 10:12 PM, Rob Landley r...@landley.net wrote:
On Sunday 29 November 2009 03:57:37 Filip Navara wrote:
On Sun, Nov 29, 2009 at 8:00 AM, Rob Landley r...@landley.net wrote:
On Friday 27 November 2009 05:35:26 Filip Navara wrote:
On Fri, Nov 27, 2009 at 12:17 PM, Vincent
On Thu, Nov 19, 2009 at 09:54:46PM +0100, Stefan Weil wrote:
Handling of transmit commands is rather complex,
so about 80 lines of code were moved from function
action_command to the new function tx_command.
The two new values tx and cb_address in the
eepro100 status structure made this
On Mon, Nov 23, 2009 at 11:30:44AM -0200, Luiz Capitulino wrote:
On Mon, 23 Nov 2009 11:44:57 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Nov 17, 2009 at 06:32:20PM -0200, Luiz Capitulino wrote:
Return a QDict with information about the just added device.
This commit
Here's the list of patches on my pci fixes tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci
I have rebased this tree to latest master and rearranged the patches in
the order of their being ready for upstream. The tree is currently on
top of qemu master: I would base it on
On Wed, Nov 25, 2009 at 12:20:05AM +0200, Michael S. Tsirkin wrote:
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,
On 11/29/2009 04:38 PM, Andreas Färber wrote:
Am 29.11.2009 um 16:29 schrieb Avi Kivity:
On 11/26/2009 07:24 PM, Glauber Costa wrote:
Since we'll have multiple cpu threads, at least for kvm, we need a
way to store
and retrieve the CPUState associated with the current execution thread.
For
Anyway on Windows neither __thread nor pthread_getspecific is supported, so
some configury is needed anyway.
Paolo
For the record, I am a big fan of __thread. The only reason I used the
pthread library was
portability. I can surely put in some configure knobs to use __thread
where available
On Sun, Nov 29, 2009 at 3:32 PM, Jan Kiszka jan.kis...@web.de wrote:
Glauber Costa wrote:
Hi guys,
This is an early version of smp support in kvm that kinda works.
It has some known problems that I am still tracking. For example,
it does not reset very well. Also, initialization is a bit
I really dislike this. In general vcpu ioctls are used as components of
some work to be done, for example RMW of some state. In this case it is
meaningless to execute the ioctls remotely, you need to execute the entire
RMW remotely instead.
Why? The M part of RMW is executed in shared
since
+ * apic base was just updated
+ */
+ kvm_arch_put_registers(s-cpu_env);
Better to use cpu_synchronize_state() instead.
I might be misreading it, but :
void kvm_cpu_synchronize_state(CPUState *env)
{
if (!env-kvm_state-regs_modified) {
On 11/26/2009 06:24 PM, Glauber Costa wrote:
+CPUState *qemu_get_current_env(void);
Useless forward reference (to a function that doesn't exist in that file
at all).
Paolo
On 11/30/2009 12:41 PM, Glauber Costa wrote:
For the record, I am a big fan of __thread. The only reason I used
the pthread library was portability. I can surely put in some
configure knobs to use __thread where available
Plus, do you really need to support SMP when __thread is not
Jan Kiszka jan.kis...@siemens.com wrote on 26/11/2009 19:24:40:
+bdrv_write(bs, (addr SECTOR_BITS),
+ buf, block_mig_state-
sectors_per_block);
This synchronous write-back translates appears to be the reason for
an
unusable migration (or restore
Liran Schour wrote:
Jan Kiszka jan.kis...@siemens.com wrote on 26/11/2009 19:24:40:
+bdrv_write(bs, (addr SECTOR_BITS),
+ buf, block_mig_state-
sectors_per_block);
This synchronous write-back translates appears to be the reason for
an
unusable
On Mon, Nov 30, 2009 at 09:45:56AM -0200, Glauber Costa wrote:
since
+ * apic base was just updated
+ */
+ kvm_arch_put_registers(s-cpu_env);
Better to use cpu_synchronize_state() instead.
I might be misreading it, but :
void kvm_cpu_synchronize_state(CPUState
On 11/30/2009 01:45 PM, Glauber Costa wrote:
Better to use cpu_synchronize_state() instead.
I might be misreading it, but :
void kvm_cpu_synchronize_state(CPUState *env)
{
if (!env-kvm_state-regs_modified) {
kvm_arch_get_registers(env);
On 11/30/2009 01:44 PM, Glauber Costa wrote:
I really dislike this. In general vcpu ioctls are used as components of
some work to be done, for example RMW of some state. In this case it is
meaningless to execute the ioctls remotely, you need to execute the entire
RMW remotely instead.
On 11/30/2009 01:49 PM, Paolo Bonzini wrote:
On 11/30/2009 12:41 PM, Glauber Costa wrote:
For the record, I am a big fan of __thread. The only reason I used
the pthread library was portability. I can surely put in some
configure knobs to use __thread where available
Plus, do you really need
Alexander Graf wrote:
While trying to run -kernel with -bios pc-bios/pcbios.bin, I realized
that I was actually writing data to %es, but only set up %ds to a 32-bit
segment we want to write to.
So at the end of the day the data hasn't actually been copied. Oops.
So here's a fix to set ES
On Mon, Nov 30, 2009 at 10:05 AM, Avi Kivity a...@redhat.com wrote:
On 11/30/2009 01:45 PM, Glauber Costa wrote:
Better to use cpu_synchronize_state() instead.
I might be misreading it, but :
void kvm_cpu_synchronize_state(CPUState *env)
{
if (!env-kvm_state-regs_modified) {
On 11/30/2009 03:31 PM, Glauber Costa wrote:
Only does get. And we need put.
It will autoput during the next guest entry.
So it should be working already, no?
We do a cpu_synchronize_state() on the beginning of that function, and
vcpu does not run
until it is finished
Yes.
On 11/30/2009 02:10 PM, Alexander Graf wrote:
Alexander Graf wrote:
While trying to run -kernel with -bios pc-bios/pcbios.bin, I realized
that I was actually writing data to %es, but only set up %ds to a 32-bit
segment we want to write to.
So at the end of the day the data hasn't actually been
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's malloc() friends. Revert that, but take care never to
return a null pointer, like malloc() friends may do (it's
implementation defined), because that's another source of bugs.
Rationale: while zero-sized
On 11/30/2009 03:55 PM, Markus Armbruster wrote:
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's malloc() friends. Revert that, but take care never to
return a null pointer, like malloc() friends may do (it's
implementation defined), because that's another
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 running Debian Lenny
Jan Kiszka wrote:
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 running
On 11/25/2009 09:18 PM, Avishay Traeger1 wrote:
This is a patch to have the guest virtio-blk driver get the value for the
maximum I/O size from the host bdrv, rather than assume that there is no
limit. Right now we use it for an in-house bdrv driver that needs this
option. The patches are
On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote:
VGA adapters need to claim memory and i/o
transactions even if they do not have any
i/o or memory bars. E.g. PCI spec, page 297,
gives an example of such a device:
Programming interface b
VGA-compatible
On Mon, Nov 30, 2009 at 04:17:22PM +0200, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote:
VGA adapters need to claim memory and i/o
transactions even if they do not have any
i/o or memory bars. E.g. PCI spec, page 297,
gives an example of such a
Jan Kiszka jan.kis...@siemens.com wrote:
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
Am 30.11.2009 14:55, schrieb Markus Armbruster:
Commit a7d27b53 made zero-sized allocations a fatal error, deviating
from ISO C's malloc() friends. Revert that, but take care never to
return a null pointer, like malloc() friends may do (it's
implementation defined), because that's another
These patches were part of series including BIOS fixes.
BIOS fixes has been applied, but it looks like qemu fixes
were forgotten. Reposting.
Reset BARs and a couple of other registers on bus reset, as per PCI
spec.
Michael S. Tsirkin (2):
qemu: make cirrus init value pci spec compliant
I want use RPC to made guest os communication with host os(both guest os
and host os are windows).How can I do this.
You'd better give me a example.
Thanks.
But why do you need that many remote calls during init? Aren't the
initial ioctls issued by the vcpu threads themselves?
Yes, but system_reset is called from the io-thread, and it fires a lot
of ioctls.
However, I have an already working version that does a much better job
than that.
Will
The proposal in this patch is to add a system_reset caller that only
resets state related to the cpu. This will guarantee that does functions
are called from the cpu-threads, not the I/O thread.
In principle, it might seem close to the remote execution mechanism, but:
* It does not involve any
On 11/30/2009 06:00 PM, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote:
VGA adapters need to claim memory and i/o
transactions even if they do not have any
i/o or memory bars. E.g. PCI spec, page 297,
gives an example of such
Michael S. Tsirkin wrote:
On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote:
VGA adapters need to claim memory and i/o
transactions even if they do not have any
i/o or memory bars. E.g. PCI spec, page 297,
gives an example of such a device:
Programming interface
On Mon, Nov 30, 2009 at 10:00:23AM -0600, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
On Thu, Oct 08, 2009 at 05:52:56PM +0200, Michael S. Tsirkin wrote:
VGA adapters need to claim memory and i/o
transactions even if they do not have any
i/o or memory bars. E.g. PCI spec, page 297,
On 11/30/2009 06:00 PM, Glauber Costa wrote:
The proposal in this patch is to add a system_reset caller that only
resets state related to the cpu. This will guarantee that does functions
are called from the cpu-threads, not the I/O thread.
In principle, it might seem close to the remote
On 11/30/2009 05:55 PM, Glauber Costa wrote:
reset code is responsible for most remote calls in qemu. One of the
only ones we still
have left is the gdb stuff. Do you have any suggestion to do that
without the current
on_vcpu mechanism?
No. But what's wrong with on_vcpu?
--
error
On Mon, Nov 30, 2009 at 2:40 PM, Avi Kivity a...@redhat.com wrote:
On 11/30/2009 05:55 PM, Glauber Costa wrote:
reset code is responsible for most remote calls in qemu. One of the
only ones we still
have left is the gdb stuff. Do you have any suggestion to do that
without the current
On Mon, Nov 30, 2009 at 2:40 PM, Avi Kivity a...@redhat.com wrote:
On 11/30/2009 05:55 PM, Glauber Costa wrote:
reset code is responsible for most remote calls in qemu. One of the
only ones we still
have left is the gdb stuff. Do you have any suggestion to do that
without the current
on_vcpu
Michael S. Tsirkin m...@redhat.com wrote:
Cirrus vga has a copy of many PCI macros,
and it doesn't even use them. Clean up.
We also don't need to override header type
as it is NORMAL by default.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/cirrus_vga.c | 36
On Sun, Nov 29, 2009 at 10:09 PM, Palle Lyckegaard pa...@lyckegaard.dk wrote:
On Sun, 29 Nov 2009, Andreas Färber wrote:
I.e. if unavoidable, instead of #define PSR_XXX 123 one might need to
#define TARGET_PSR_XXX 123 and change *all* uses of PSR_XXX to
TARGET_PSR_XXX, so that Sun's and
Michael S. Tsirkin schrieb:
On Thu, Nov 19, 2009 at 09:54:46PM +0100, Stefan Weil wrote:
Handling of transmit commands is rather complex,
so about 80 lines of code were moved from function
action_command to the new function tx_command.
The two new values tx and cb_address in the
eepro100
Ian Molton wrote:
Hi folks,
I need my source of data for virtio-rng to be reliable - IOW. if the
server dies and comes back up, I want qemu to reconnect and suck down
fresh entropy, rather than hand the rngd process on the guest.
I'm using the chardev 'socket' type to make the connection to
Both functions share a lot of code, so make them one.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 149 ++---
1 files changed, 50 insertions(+), 99 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
migration.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/migration.c b/migration.c
index dcde7c3..d7fb756 100644
--- a/migration.c
+++ b/migration.c
@@ -58,7 +58,13 @@ void do_migrate(Monitor *mon, const
4K is too small for efficiently saving and restoring multi-GB block
devices.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block.h b/block.h
index 3513712..4a8b628 100644
--- a/block.h
+++ b/block.h
@@
Besides catching real errors, this also allows to interrrupt the qemu
process during restore.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
vl.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/vl.c b/vl.c
index ee43808..64426aa 100644
--- a/vl.c
+++ b/vl.c
This switches the dirty bitmap to a true bitmap, reducing its footprint
(specifically in caches). It moreover fixes off-by-one bugs in
set_dirty_bitmap (nb_sectors+1 were marked) and bdrv_get_dirty (limit
check allowed one sector behind end of drive). And is drops redundant
dirty_tracking field
Move a potentially large buffer from stack to heap.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 5aff5a7..a0dcdad 100644
---
In order to allow proper progress reporting to the monitor that
initiated the migration, forward the monitor reference through the
migration layer down to SaveLiveStateHandler.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c |2 +-
hw/hw.h |3 ++-
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 32
block-migration.h |4
migration.c |9 +
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index
qemu_fclose frees the passed file structure, but do_migrate_set_speed
may access it later on. Fix it by setting file NULL in
migrate_fd_cleanup and checking for this.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
migration.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 24
block-migration.h |2 +-
2 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index f6fac73..f81cf35 100644
--- a/block-migration.c
+++
Introduce qemu_savevm_state_cancel and inject a stage -1 to cancel a
live migration. This gives the involved subsystems a chance to clean up
dynamically allocated resources. Namely, the block migration layer can
now free its device descriptors and pending blocks.
Signed-off-by: Jan Kiszka
No functional changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 390 +
block-migration.h | 10 -
block.c | 49 ---
block.h |4 -
4 files changed, 212 insertions(+), 241
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 57 ++---
1 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 81709aa..5997f9b 100644
--- a/block-migration.c
+++
We already save total_sectors in BlkMigDevState, let's use this value
during the migration and avoid to recalculate it needlessly.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
Based on the original patch by Pierre Riteau: Use a common blk_send
function to transmit a block.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 104 -
1 files changed, 39 insertions(+), 65 deletions(-)
diff --git
From: Pierre Riteau pierre.rit...@irisa.fr
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-queue.h | 109 --
1 files changed, 105 insertions(+), 4 deletions(-)
diff --git
Based on the original patch by Pierre Riteau.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 57 -
1 files changed, 22 insertions(+), 35 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index
Inject progress report in percentage into the block live stream. This
can be read out and displayed easily on restore.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git
So far progress reporting only works for the first block device. Fix
this by keeping an overall sum of sectors to be migratated, calculating
the sum of all processed sectors, and finally basing the progress
display on those values.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
No need to push block_mig_state to the heap and, thus, establish an
indirection.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 91 ++---
1 files changed, 44 insertions(+), 47 deletions(-)
diff --git
This series is a larger rework of the block migration support qemu
recently gained. Besides lots of code refactorings the major changes
are:
- Faster restore due to larger block sizes (even if the target disk is
unallocated)
- Off-by-one fixes in the block dirty tracking code
- Allow for
In case we restart a migration, submitted, read_done, transferred, and
print_completion need to be reinitialized to 0.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block-migration.c
Report progress of an outgoing live migration to the monitor instead of
stdout.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 54 +
1 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/block-migration.c
Instead of duplicating the definition of constants or introducing
trivial retrieval functions move the SECTOR constants into the public
block API. This also obsoletes sector_per_block in BlkMigState.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
block-migration.c | 63
Glauber Costa wrote:
On Mon, Nov 30, 2009 at 2:40 PM, Avi Kivity a...@redhat.com wrote:
On 11/30/2009 05:55 PM, Glauber Costa wrote:
reset code is responsible for most remote calls in qemu. One of the
only ones we still
have left is the gdb stuff. Do you have any suggestion to do that
Jan Kiszka wrote:
This series is a larger rework of the block migration support qemu
recently gained. Besides lots of code refactorings the major changes
are:
- Faster restore due to larger block sizes (even if the target disk is
unallocated)
- Off-by-one fixes in the block dirty tracking
On 30 nov. 2009, at 19:34, Anthony Liguori wrote:
Jan Kiszka wrote:
This series is a larger rework of the block migration support qemu
recently gained. Besides lots of code refactorings the major changes
are:
- Faster restore due to larger block sizes (even if the target disk is
On Thu, Nov 26, 2009 at 01:24:22PM +0100, Alexander Graf wrote:
Hm - maybe worth a try to give it a -L to the source pc-bios directory
anyways.
Doesn't change a thing.
Sounds like your guest kernel is trying to access an x86_64 register?
You can of cause try insmod'ing kvm.ko with
Anthony Liguori wrote:
Jan Kiszka wrote:
This series is a larger rework of the block migration support qemu
recently gained. Besides lots of code refactorings the major changes
are:
- Faster restore due to larger block sizes (even if the target disk is
unallocated)
- Off-by-one fixes
On 11/30/2009 08:50 PM, Christoph Hellwig wrote:
Sounds like your guest kernel is trying to access an x86_64 register?
You can of cause try insmod'ing kvm.ko with ignore_msrs=1. You hopefully
don't need syscalls until you get into user space.
The option doesn't exist yet in 2.6.31
These patches were part of series including BIOS fixes.
BIOS fixes has been applied, but it looks like qemu fixes
were forgotten. Reposting.
Reset BARs and a couple of other registers on bus reset, as per PCI
spec.
This fixes up posting v4 which was garbled, sorry about that.
Michael S.
PCI memory should be disabled at reset, otherwise
we might claim transactions at address 0.
I/O should also be disabled, although for cirrus
it is harmless to enable it as we do not
have I/O bar.
Note: bios fix needed for this patch to work
was already applied:
previously bios incorrently assumed
Cirrus vga has a copy of many PCI macros,
and it doesn't even use them. Clean up.
We also don't need to override header type
as it is NORMAL by default.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Acked-by: Juan Quintela quint...@redhat.com
---
hw/cirrus_vga.c | 35
On 30 nov. 2009, at 19:50, Pierre Riteau wrote:
I'm currently testing these patches. Here are a few issues I noticed, before
I forget about them.
- migrate -d -b tcp:dest:port works, but migrate -b -d tcp:dest:port
doesn't, although help migrate doesn't really specify ordering as
On Sat, Nov 28, 2009 at 11:17:20AM +0100, Aurelien Jarno wrote:
On Mon, Nov 23, 2009 at 12:49:59PM -0800, Nathan Froyd wrote:
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/cpu.h |1 +
target-mips/translate.c |2 ++
2 files changed, 3
On Thu, Nov 26, 2009 at 02:23:17PM +0100, Alexander Graf wrote:
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!
Please find the
On Thu, Nov 26, 2009 at 02:23:13PM +0100, Alexander Graf wrote:
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
On Thu, Nov 26, 2009 at 02:23:12PM +0100, Alexander Graf wrote:
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,
On Thu, Nov 26, 2009 at 02:23:14PM +0100, Alexander Graf wrote:
KVM on S390x requires the virtual address space of the guest's RAM to be
within the first 256GB.
While I have no problem with this patch, I am curious to know the reason
of this. No need to change anything in the patch.
The
On Thu, Nov 26, 2009 at 02:23:10PM +0100, Alexander Graf wrote:
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
Hi,
On Thu, Nov 26, 2009 at 02:23:09PM +0100, Alexander Graf wrote:
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
On Thu, Nov 26, 2009 at 02:23:15PM +0100, Alexander Graf wrote:
Let's enable the basics for system emulation so we can run virtual machines
with KVM!
I don't really understand while this whole patch is not merged in patch
number 1. Otherwise, please find the comments below.
Signed-off-by:
On 30 nov. 2009, at 20:25, Jan Kiszka wrote:
Pierre Riteau wrote:
On 30 nov. 2009, at 19:34, Anthony Liguori wrote:
Jan Kiszka wrote:
This series is a larger rework of the block migration support qemu
recently gained. Besides lots of code refactorings the major changes
are:
- Faster
Pierre Riteau wrote:
On 30 nov. 2009, at 19:50, Pierre Riteau wrote:
I'm currently testing these patches. Here are a few issues I noticed, before
I forget about them.
- migrate -d -b tcp:dest:port works, but migrate -b -d tcp:dest:port
doesn't, although help migrate doesn't really
Pierre Riteau wrote:
On 30 nov. 2009, at 20:25, Jan Kiszka wrote:
Pierre Riteau wrote:
On 30 nov. 2009, at 19:34, Anthony Liguori wrote:
Jan Kiszka wrote:
This series is a larger rework of the block migration support qemu
recently gained. Besides lots of code refactorings the major
Gleb Natapov wrote:
On Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote:
Gleb Natapov wrote:
On Wed, Nov
On Mon, Nov 30, 2009 at 06:05:31PM +0100, Stefan Weil wrote:
Michael S. Tsirkin schrieb:
On Thu, Nov 19, 2009 at 09:54:46PM +0100, Stefan Weil wrote:
Handling of transmit commands is rather complex,
so about 80 lines of code were moved from function
action_command to the new function
On Mon, Nov 30, 2009 at 04:54:31PM +0100, Kevin Wolf wrote:
Users don't expect that they need to specify host_device/cdrom/floppy when
creating an image on a block device or converting with an device as target.
Currently creating as raw leads to 'Error while formatting' whereas using as
raw
Gleb Natapov wrote:
On Sun, Nov 29, 2009 at 10:53:40PM +, Natalia Portillo wrote:
We already concluded that return to PM by triple fault is not
something
we want to support. It was needed only on 286 and QEMU doesn't even
support 286 cpu emulation.
It is used by a whole kind
I386 has native way to switch to PM, no need triple fault trick and
it
was introduced by Intel in 1985. For those who wanted to be
compatible
with 286 there was a trick invented back then to switch to PM in a
portable way between i386 and i286:
This patch changes the monitor eject_device() function to not check for
bdrv_is_inserted().
Example run where the bug manifests itself:
(output of 'info block' is stripped to include only the CD-ROM device)
QEMU 0.11.50 monitor - type 'help' for more information
(qemu) info block
Currently we have this stupid role of disallowing:
if (r)
break;
By disallowing this we clutter the code, making it less readable without
buying us anything. In fact, nobody actually sticks to this because it'd show
just how much bad taste the programmer doing this would have.
So IMHO
On 30.11.2009, at 19:18, Aurelien Jarno wrote:
On Thu, Nov 26, 2009 at 02:23:15PM +0100, Alexander Graf wrote:
Let's enable the basics for system emulation so we can run virtual machines
with KVM!
I don't really understand while this whole patch is not merged in patch
number 1. Otherwise,
1 - 100 of 111 matches
Mail list logo
