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 wrote:
> On Sunday 29 November 2009 03:57:37 Filip Navara wrote:
>> On Sun, Nov 29, 2009 at 8:00 AM, Rob Landley wrote:
>> > On Friday 27 November 2009 05:35:26 Filip Navara wrote:
>> >> On Fri, Nov 27, 2009 at 12:17 PM, Vincent Sanders
>> >
>> > wro
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
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" 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 sh
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 stagi
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 la
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 the
> 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 availabl
On Sun, Nov 29, 2009 at 3:32 PM, Jan Kiszka 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 slow,
>> p
>
> 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 sha
>> 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) {
kvm_ar
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 available?..
Jan Kiszka 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 f
Liran Schour wrote:
>
> Jan Kiszka 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
> unusa
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_sync
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);
env->kvm_state->regs_modi
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.
W
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 to
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
On Mon, Nov 30, 2009 at 10:05 AM, Avi Kivity 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 allocat
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 s
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 Debian Lenny 32-bit.
>> Symtoms:
Jan Kiszka wrote:
> 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 Debian L
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 below
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 co
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
Jan Kiszka wrote:
> 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 Debian
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 anot
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
qemu
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
---
hw/cirrus_vga.c | 36 +---
1 files changed, 1 insertions(+), 35 deletio
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.
I haven't heard yet of anyone using qemu-img to copy an image to a real floppy,
but it's a valid use case.
Signed-off-by: Kevin Wolf
---
block/raw-posix.c |4
block_int.h |3 +++
qemu-img.c|4 ++--
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/bloc
>> 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 th
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 just works.
With this patch raw is accepted for both files and h
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 ex
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 a
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 000
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 29
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 executio
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 compili
On Mon, Nov 30, 2009 at 2:40 PM, Avi Kivity 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 m
On Mon, Nov 30, 2009 at 2:40 PM, Avi Kivity 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 mechanism?
No.
"Michael S. Tsirkin" 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
> ---
> hw/cirrus_vga.c | 36 +---
>
On Sun, Nov 29, 2009 at 10:09 PM, Palle Lyckegaard 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 QEMU's definition
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 th
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 the
Both functions share a lot of code, so make them one.
Signed-off-by: Jan Kiszka
---
block-migration.c | 149 ++---
1 files changed, 50 insertions(+), 99 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 2f89a4e..99fe333 10064
Signed-off-by: Jan Kiszka
---
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 QDict *qdict, QObject
**re
4K is too small for efficiently saving and restoring multi-GB block
devices.
Signed-off-by: Jan Kiszka
---
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
@@ -192,7 +192,7 @@ int bdrv_s
Besides catching real errors, this also allows to interrrupt the qemu
process during restore.
Signed-off-by: Jan Kiszka
---
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
@@ -3017,8 +3017,12 @@ s
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 fro
Move a potentially large buffer from stack to heap.
Signed-off-by: Jan Kiszka
---
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
--- a/block-migration.c
+++ b/block-migra
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
---
block-migration.c |2 +-
hw/hw.h |3 ++-
migration-exec.c | 12
Signed-off-by: Jan Kiszka
---
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 22d10f0..7510923 100644
--- a/bl
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
---
migration.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/migratio
Signed-off-by: Jan Kiszka
---
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
+++ b/block-migration.c
@@ -59
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
---
b
No functional changes.
Signed-off-by: Jan Kiszka
---
block-migration.c | 390 +
block-migration.h | 10 -
block.c | 49 ---
block.h |4 -
4 files changed, 212 insertions(+), 241 deletions(-)
diff --git a/block
Signed-off-by: Jan Kiszka
---
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
+++ b/block-migration.c
@@ -1
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
---
block-migration.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/block-migration.c b/block-migration.c
Based on the original patch by Pierre Riteau: Use a common blk_send
function to transmit a block.
Signed-off-by: Jan Kiszka
---
block-migration.c | 104 -
1 files changed, 39 insertions(+), 65 deletions(-)
diff --git a/block-migration.c b/bl
From: Pierre Riteau
Signed-off-by: Pierre Riteau
Signed-off-by: Jan Kiszka
---
qemu-queue.h | 109 --
1 files changed, 105 insertions(+), 4 deletions(-)
diff --git a/qemu-queue.h b/qemu-queue.h
index 8877efd..1d07745 100644
--- a/qemu-
Based on the original patch by Pierre Riteau.
Signed-off-by: Jan Kiszka
---
block-migration.c | 57 -
1 files changed, 22 insertions(+), 35 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index f81cf35..6ca48f4 100644
--- a/
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
---
block-migration.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/block-migration.c b/bloc
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
---
block-migration.c | 46
No need to push block_mig_state to the heap and, thus, establish an
indirection.
Signed-off-by: Jan Kiszka
---
block-migration.c | 91 ++---
1 files changed, 44 insertions(+), 47 deletions(-)
diff --git a/block-migration.c b/block-migration.c
i
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 mult
In case we restart a migration, submitted, read_done, transferred, and
print_completion need to be reinitialized to 0.
Signed-off-by: Jan Kiszka
---
block-migration.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 6ca48f4
Report progress of an outgoing live migration to the monitor instead of
stdout.
Signed-off-by: Jan Kiszka
---
block-migration.c | 54 +
1 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/block-migration.c b/block-migration.c
in
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
---
block-migration.c | 63 +++-
Glauber Costa wrote:
> On Mon, Nov 30, 2009 at 2:40 PM, Avi Kivity 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
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 co
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 igno
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
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 which
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. Tsirki
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
Acked-by: Juan Quintela
---
hw/cirrus_vga.c | 35 ---
1 files changed, 0 i
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 a
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 restore due to larger block sizes (e
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
> > ---
> > target-mips/cpu.h |1 +
> > target-mips/translate.c |2 ++
> > 2 files changed, 3 insertions(+), 0 deletio
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 co
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
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 possi
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 t
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 (http://www.i
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: A
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
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" does
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 refact
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 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 fu
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
> r
1 - 100 of 118 matches
Mail list logo
