On 30.11.2009, at 23:26, Adam Lackorzynski wrote:
> multiboot: Support arbitrary number of modules
Sounds like it's about time to extract the multiboot code from pc.c and move it
to multiboot.c. After all, multiboot is supported on non-x86 as well, so maybe
we can reuse some code here.
Alex
On Mon, Nov 30, 2009 at 08:53:35PM +, Jamie Lokier wrote:
> Gleb Natapov wrote:
> > I doubt that OS/2 was not updated to use something like this.
>
> I can't test 16-bit OS/2, so if someone would like to give it a try
> that'd be great. It'd be interesting to see what method it uses.
I've te
On Mon, Nov 30, 2009 at 4:31 PM, Ed Swierk wrote:
> On Thu, Nov 26, 2009 at 9:24 AM, Glauber Costa wrote:
>> This is an early version of smp support in kvm that kinda works.
>
> Can you please elaborate on "smp support"? The KVM FAQ makes some
> rather broad claims about smp support already:
I s
On Thu, Nov 26, 2009 at 9:24 AM, Glauber Costa wrote:
> This is an early version of smp support in kvm that kinda works.
Can you please elaborate on "smp support"? The KVM FAQ makes some
rather broad claims about smp support already:
Does KVM support SMP hosts?
Yes.
Does KVM support SMP g
"Michael S. Tsirkin" wrote:
> 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 gar
On 30.11.2009, at 19:18, Aurelien Jarno wrote:
> 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 emulat
On 30.11.2009, at 19:18, Aurelien Jarno wrote:
> 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 t
multiboot: Support arbitrary number of modules
Signed-off-by: Adam Lackorzynski
---
hw/pc.c | 216 +-
1 files changed, 143 insertions(+), 73 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 6bcfe1b..163bec1 100644
--- a/hw/pc.c
+++
multiboot: Fix module loading and setting of mmap.
Signed-off-by: Adam Lackorzynski
Acked-by: Alexander Graf
---
hw/pc.c |2 +-
pc-bios/multiboot.bin | Bin 512 -> 1024 bytes
pc-bios/optionrom/multiboot.S |5 -
3 files changed, 5 insertions(+), 2 delet
On 30.11.2009, at 19:18, Aurelien Jarno wrote:
> 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 u
This implements the audio control or volume read support as needed by
some systems. A Conectiva Parolin system required this to detect an IDE
device as CD-ROM, through the CDVOLREAD ioctl.
Signed-off-by: Thadeu Lima de Souza Cascardo
---
hw/ide/core.c | 17 +
1 files changed, 1
Some PAGE constants were used instead of the macros we already have
defined in internal.h.
Signed-off-by: Thadeu Lima de Souza Cascardo
---
hw/ide/core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 7b1ff8f..b551adf 100644
--- a/
On 30.11.2009, at 19:18, Aurelien Jarno wrote:
> 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
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. Oth
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 we
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
ide1-cd0:
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:
http://www.rcollins.org/ftp/source/3fault/reset
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
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
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
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:
>
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
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
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
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
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: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
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: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: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: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 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
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 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
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
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
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
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
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 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
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
>>
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
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
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 +++-
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
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
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
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
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
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
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/
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: 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
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
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
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
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
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
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 | 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
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
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
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
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
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
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
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
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
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
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" 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 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.
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 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 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 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
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 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
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
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
>> 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
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
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.
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
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
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
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
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
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
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 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
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
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:
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
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 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
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 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
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 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
1 - 100 of 118 matches
Mail list logo
