Hi Anthony,
I started a guest with cache=none and aio=threads
When i did some io tests in Guest say dd like
dd if=/dev/zero oflag=direct of=/mnt/sdb1/date.img bs=4k count=262114
qemu will start one or several threads to perform IO requests.
It seems qemu makes use of its own posixaio. I'm wonde
On 08/03/2011 05:33 AM, Anthony Liguori wrote:
On 08/02/2011 04:29 PM, Avi Kivity wrote:
On 08/03/2011 12:06 AM, Anthony Liguori wrote:
The qdev level should be the common base that makes sense for *all*
qdev devices. IRQ management does not belong in DeviceState because
what you do for a simp
On 08/03/2011 05:26 AM, Anthony Liguori wrote:
On 08/02/2011 04:48 PM, Avi Kivity wrote:
On 08/03/2011 12:28 AM, Peter Maydell wrote:
On 2 August 2011 21:56, Anthony Liguori wrote:
> Hrm, this looks like badness to me.
>
> You're effectively using MemoryRegions to implement an ad-hoc
interface.
On 08/03/2011 02:12 AM, Anthony Liguori wrote:
Paolo's proposed changes make newer QEMUs use a new protocol. It's
still possible to read the older protocol. This means that you can't
migrate new to old, but can migrate old to new.
Not really true, with my series you can migrate new to old if
On 08/02/2011 11:01 PM, Stefan Weil wrote:
I run cross builds for arm, mips, powerpc and mingw.
All of them use the cross prefix. When running make,
I neither want to specify a special PATH nor a
PKG_CONFIG_PATH. All I need is something like
"make -C bin/arm" (each cross target has its own
direc
Hi Anthony,
I started a guest with cache=none and aio=threads
When i did some io tests in Guest say dd like
dd if=/dev/zero oflag=direct of=/mnt/sdb1/date.img bs=4k count=262114
qemu will start one or several threads to perform IO requests.
It seems qemu makes use of its own posixaio. I'm wonde
On 2011-08-03 02:18, Anthony Liguori wrote:
> As Paolo points out, the migration protocol is ambiguous when using
> subsections
> today. That means that even if we preserve subsections and change the
> protocol
> accordingly, the old protocol w/subsections is still ambiguous.
>
> Remove subsect
On Wed, 2011-08-03 at 12:04 +1000, David Gibson wrote:
> On Tue, Aug 02, 2011 at 12:35:19PM -0600, Alex Williamson wrote:
> > On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
> > > On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
> > > > On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex
On 01/08/11 5:35 PM, Blue Swirl wrote:
On Mon, Aug 1, 2011 at 12:33 AM, Brad wrote:
I know sparc64 had little chance of actually working but
I thought I'd take it for a spin with 0.15.0-rc1 and
see how it fared in addition to macppc which has a good
chance of working nowdays with modern QEMU. L
On 08/02/2011 04:29 PM, Avi Kivity wrote:
On 08/03/2011 12:06 AM, Anthony Liguori wrote:
The qdev level should be the common base that makes sense for *all*
qdev devices. IRQ management does not belong in DeviceState because
what you do for a simple LCD is not what you do for an MSI-X capable
P
On 08/02/2011 04:48 PM, Avi Kivity wrote:
On 08/03/2011 12:28 AM, Peter Maydell wrote:
On 2 August 2011 21:56, Anthony Liguori wrote:
> Hrm, this looks like badness to me.
>
> You're effectively using MemoryRegions to implement an ad-hoc
interface.
As you'll see below, the hardware intreface is
On 08/02/2011 04:28 PM, Peter Maydell wrote:
On 2 August 2011 21:56, Anthony Liguori wrote:
Hrm, this looks like badness to me.
You're effectively using MemoryRegions to implement an ad-hoc interface.
As you'll see below, the hardware intreface is somewhat ad-hoc :-)
This is not what Mem
On Tue, Aug 02, 2011 at 12:35:19PM -0600, Alex Williamson wrote:
> On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
> > On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
> > > On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
> > > > On Sat, 2011-07-30 at 09:58 +1000, B
Hi,
I want -rc2 to be the final build so I'm delaying -rc3 until tomorrow so
we can sort out how to handle this migration issue.
I've updated the wiki and posted my candidate branch to:
http://repo.or.cz/w/qemu/aliguori.git/shortlog/refs/heads/stable-0.15
We will still have the release on th
As Paolo points out, the migration protocol is ambiguous when using subsections
today. That means that even if we preserve subsections and change the protocol
accordingly, the old protocol w/subsections is still ambiguous.
Remove subsection usage and bump any device using subsections. This effec
On 08/02/2011 06:25 PM, Juan Quintela wrote:
Anthony Liguori wrote:
As Paolo points out, the migration protocol is ambiguous when using subsections
today. That means that even if we preserve subsections and change the protocol
accordingly, the old protocol w/subsections is still ambiguous.
Re
Anthony Liguori wrote:
> As Paolo points out, the migration protocol is ambiguous when using
> subsections
> today. That means that even if we preserve subsections and change the
> protocol
> accordingly, the old protocol w/subsections is still ambiguous.
>
> Remove subsection usage and bump an
On 08/02/2011 06:08 PM, Anthony Liguori wrote:
As Paolo points out, the migration protocol is ambiguous when using subsections
today. That means that even if we preserve subsections and change the protocol
accordingly, the old protocol w/subsections is still ambiguous.
Remove subsection usage a
As Paolo points out, the migration protocol is ambiguous when using subsections
today. That means that even if we preserve subsections and change the protocol
accordingly, the old protocol w/subsections is still ambiguous.
Remove subsection usage and bump any device using subsections. This effec
On 07/29/2011 10:33 AM, Paolo Bonzini wrote:
With the current migration format, VMS_STRUCTs with subsections
are ambiguous. The protocol cannot tell whether a 0x5 byte after
the VMS_STRUCT is a subsection or part of the parent data stream.
In the past QEMU assumed it was always a part of a subse
On 08/02/2011 05:01 PM, Alexander Graf wrote:
So if I understand correctly, this enabled delta updates for dirty pages? Would
it be possible to do the same on the block layer, so that VM backing file data
could potentially save the new information as delta over the old block?
Especially with m
On 08/02/2011 03:06 PM, Avi Kivity wrote:
> I don't think there's any cpu which has a real 64-bit physical
> address space? Don't they all truncate it?
I don't know. You're right that x86_64 does, at 48 bits.
The alpha system I'm trying to emulate does, at 50 bits.
I guess if IBM agrees wrt p-se
On 08/03/2011 12:59 AM, Richard Henderson wrote:
On 08/02/2011 01:50 PM, Avi Kivity wrote:
> struct AddrRange {
> -uint64_t start;
> -uint64_t size;
> +int64_t start;
> +int64_t size;
I'm must say I'm not keen on this. My primary objection is that
a "range" can no longer p
On 2 August 2011 22:48, Avi Kivity wrote:
> On 08/03/2011 12:28 AM, Peter Maydell wrote:
>> As you'll see below, the hardware intreface is somewhat ad-hoc :-)
>
> IMO it fits perfectly into a qdev which contains 8 qbuses, each of which is
> connected to another qdev.
Yeah. I don't much like the w
On 08/02/2011 01:50 PM, Avi Kivity wrote:
> struct AddrRange {
> -uint64_t start;
> -uint64_t size;
> +int64_t start;
> +int64_t size;
I'm must say I'm not keen on this. My primary objection is that
a "range" can no longer properly represent the entire address space.
Or, indeed,
On Tue, 2 Aug 2011, Jan Beulich wrote:
> >>> Anthony PERARD 08/01/11 9:27 PM >>>
> >Previously, the address space soft limit was set mcache_max_size. So,
> >before the mcache_max_size was reached by the mapcache, QEMU was killed
> >for overuse of the virtual address space.
> >
> >This patch fix
On Mon, 1 Aug 2011, Anthony PERARD wrote:
> Previously, the address space soft limit was set mcache_max_size. So,
> before the mcache_max_size was reached by the mapcache, QEMU was killed
> for overuse of the virtual address space.
>
> This patch fix that by setting the soft limit to mcache_max_si
On 08/03/2011 12:28 AM, Peter Maydell wrote:
On 2 August 2011 21:56, Anthony Liguori wrote:
> Hrm, this looks like badness to me.
>
> You're effectively using MemoryRegions to implement an ad-hoc interface.
As you'll see below, the hardware intreface is somewhat ad-hoc :-)
IMO it fits perf
On 08/03/2011 12:06 AM, Anthony Liguori wrote:
The qdev level should be the common base that makes sense for *all*
qdev devices. IRQ management does not belong in DeviceState because
what you do for a simple LCD is not what you do for an MSI-X capable
PCI device.
This is what QOM propertie
On 2 August 2011 21:56, Anthony Liguori wrote:
> Hrm, this looks like badness to me.
>
> You're effectively using MemoryRegions to implement an ad-hoc interface.
As you'll see below, the hardware intreface is somewhat ad-hoc :-)
> This is not what MemoryRegions are meant to do though. You want
On 08/02/2011 10:38 PM, Peter Maydell wrote:
On 2 August 2011 20:11, Avi Kivity wrote:
> On 08/02/2011 09:21 PM, Peter Maydell wrote:
>>
>> On 2 August 2011 19:05, Avi Kivitywrote:
>> >On 08/02/2011 08:21 PM, Peter Maydell wrote:
>> >>So I think we just need a sysbus_mmio_get_mem
On 08/03/2011 12:15 AM, malc wrote:
On Tue, 2 Aug 2011, Avi Kivity wrote:
> When trying to map an alias of a ram region, where the alias starts at
> address A and we map it into address B, and A> B, we had an arithmetic
> underflow. Because we use unsigned arithmetic, the underflow converte
On Tue, 2 Aug 2011, Avi Kivity wrote:
> When trying to map an alias of a ram region, where the alias starts at
> address A and we map it into address B, and A > B, we had an arithmetic
> underflow. Because we use unsigned arithmetic, the underflow converted
> into a large number which failed addr
On 08/02/2011 01:07 PM, Jan Kiszka wrote:
On 2011-08-02 19:21, Peter Maydell wrote:
On 2 August 2011 16:58, Avi Kivity wrote:
On 08/02/2011 06:47 PM, Peter Maydell wrote:
This kind of "I want to manage the memory layout of a pile of other
things" seems like what the hierarchical memory API sh
Am 02.08.2011 22:21, schrieb Stuart yoder:
From: Stuart Yoder
the host pkg-config tool should be used with the location to
pkg-config *.pc files being specified via the PKG_CONFIG_PATH
Signed-off-by: Stuart Yoder
---
The Freescale cross build environment is multilib which
means there are spe
On 08/02/2011 02:38 PM, Peter Maydell wrote:
On 2 August 2011 20:11, Avi Kivity wrote:
On 08/02/2011 09:21 PM, Peter Maydell wrote:
On 2 August 2011 19:05, Avi Kivitywrote:
On 08/02/2011 08:21 PM, Peter Maydell wrote:
So I think we just need a sysbus_mmio_get_memoryregion()
(and c
On 08/02/2011 01:21 PM, Peter Maydell wrote:
On 2 August 2011 19:05, Avi Kivity wrote:
On 08/02/2011 08:21 PM, Peter Maydell wrote:
So I think we just need a sysbus_mmio_get_memoryregion()
(and convert the devices I need to attach to use memory
regions, and live with not being able to attach u
When trying to map an alias of a ram region, where the alias starts at
address A and we map it into address B, and A > B, we had an arithmetic
underflow. Because we use unsigned arithmetic, the underflow converted
into a large number which failed addrrange_intersects() tests.
The concrete example
From: Stuart Yoder
the host pkg-config tool should be used with the location to
pkg-config *.pc files being specified via the PKG_CONFIG_PATH
Signed-off-by: Stuart Yoder
---
The Freescale cross build environment is multilib which
means there are special library paths for different
cpu types
On 2 August 2011 20:11, Avi Kivity wrote:
> On 08/02/2011 09:21 PM, Peter Maydell wrote:
>>
>> On 2 August 2011 19:05, Avi Kivity wrote:
>> > On 08/02/2011 08:21 PM, Peter Maydell wrote:
>> >> So I think we just need a sysbus_mmio_get_memoryregion()
>> >> (and convert the devices I need to att
On 08/02/2011 02:06 PM, Luiz Capitulino wrote:
On Tue, 2 Aug 2011 10:03:30 +0800
TeLeMan wrote:
This patch introduces "-mms-bitfields" cflag on MinGW but this cflag
breaks gcc packed structures("__attribute__((packed))"). For example,
slirp does not work on Win32.
I'm not familiar with MinGW
On 08/02/2011 09:07 PM, Jan Kiszka wrote:
>>
>>
>> system_memory
>> |
>> +--- cs_region-0
>> |
>> +--- device-connected-to-that-region
>>
>> cs-region-0 will clip anything under it.
>
> OK, and when we change the size of CS0 we delete the container
> regio
On 08/02/2011 09:21 PM, Peter Maydell wrote:
On 2 August 2011 19:05, Avi Kivity wrote:
> On 08/02/2011 08:21 PM, Peter Maydell wrote:
>> So I think we just need a sysbus_mmio_get_memoryregion()
>> (and convert the devices I need to attach to use memory
>> regions, and live with not being abl
On Fri, Jul 29, 2011 at 04:57:26PM -0400, Umesh Deshpande wrote:
> This patch creates a separate dirty bitmap for each slot. Currently dirty
> bitmap
> is created for addresses ranging from 0 to the end address of the last memory
> slot. Since the memslots are not necessarily contiguous, current b
On Fri, Jul 29, 2011 at 04:57:25PM -0400, Umesh Deshpande wrote:
> In the migration thread, qemu_mutex is released during the most time consuming
> part. i.e. during is_dup_page which identifies the uniform data pages and
> during
> the put_buffer. qemu_mutex is also released while blocking on sel
On Tue, 2 Aug 2011 11:22:15 +0100
"Daniel P. Berrange" wrote:
> On Thu, Jul 28, 2011 at 10:31:43AM -0300, Luiz Capitulino wrote:
> > On Thu, 28 Jul 2011 10:23:22 +0300
> > Avi Kivity wrote:
> >
> > > On 07/28/2011 12:44 AM, Blue Swirl wrote:
> > > > On Wed, Jul 27, 2011 at 9:42 PM, Luiz
> > >
On Tue, 2 Aug 2011 10:03:30 +0800
TeLeMan wrote:
> This patch introduces "-mms-bitfields" cflag on MinGW but this cflag
> breaks gcc packed structures("__attribute__((packed))"). For example,
> slirp does not work on Win32.
I'm not familiar with MinGW (or why glib would require that flag).
Mich
On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
> On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
> > On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
> > > On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
> > [snip]
> > > On x86, the USB controllers
On 2 August 2011 19:05, Avi Kivity wrote:
> On 08/02/2011 08:21 PM, Peter Maydell wrote:
>> So I think we just need a sysbus_mmio_get_memoryregion()
>> (and convert the devices I need to attach to use memory
>> regions, and live with not being able to attach unconverted
>> devices).
>
> I don't fo
On Tue, Aug 02, 2011 at 03:45:51PM +0200, Shribman, Aidan wrote:
> > From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> > Sent: Thursday, July 07, 2011 11:23 AM
> > To: Shribman, Aidan
> > Cc: qemu-devel@nongnu.org; Anthony Liguori
> > Subject: Re: [PATCH v2] XBRLE page delta compression for live
On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
> On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
> > On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
> [snip]
> > On x86, the USB controllers don't typically live behind a PCIe-to-PCI
> > bridge, so don't suff
On Tue, Aug 02, 2011 at 04:01:06PM +0200, Alexander Graf wrote:
>
> On 02.08.2011, at 15:45, Shribman, Aidan wrote:
>
> > Subject: [PATCH v3] XBZRLE delta for live migration of large memory apps
> > From: Aidan Shribman
> >
> > By using XBZRLE (Xor Binary Zero Run-Length-Encoding) we can reduce
On 2011-08-02 19:21, Peter Maydell wrote:
> On 2 August 2011 16:58, Avi Kivity wrote:
>> On 08/02/2011 06:47 PM, Peter Maydell wrote:
>>> This kind of "I want to manage the memory layout of a pile of other
>>> things" seems like what the hierarchical memory API should provide,
>>> but there's a bi
On Tue, Aug 02, 2011 at 03:45:56PM +0200, Shribman, Aidan wrote:
> Subject: [PATCH v3] XBZRLE delta for live migration of large memory apps
> From: Aidan Shribman
>
> By using XBZRLE (Xor Binary Zero Run-Length-Encoding) we can reduce VM
> downtime
> and total live-migration time for VMs running
On 08/02/2011 08:21 PM, Peter Maydell wrote:
On 2 August 2011 16:58, Avi Kivity wrote:
> On 08/02/2011 06:47 PM, Peter Maydell wrote:
>> This kind of "I want to manage the memory layout of a pile of other
>> things" seems like what the hierarchical memory API should provide,
>> but there's a
Hi,
I was looking at trying to get soc_dma to call a fifo routine using
soc_dma_port_add_fifo_in and hit a few problems that are fixed by the following
patch.
1) Where there are two entries matching an address (i.e. a fifo registered for
both input and output) soc_dma_lookup finds the last on
On 2 August 2011 16:58, Avi Kivity wrote:
> On 08/02/2011 06:47 PM, Peter Maydell wrote:
>> This kind of "I want to manage the memory layout of a pile of other
>> things" seems like what the hierarchical memory API should provide,
>> but there's a bit of a difficulty here in that sysbus MMIOs aren
LinkedIn
pushparaj muthu requested to add you as a connection on LinkedIn:
--
Jiajun,
I'd like to add you to my professional network on LinkedIn.
- pushparaj
Accept invitation from pushparaj muthu
http://www.linkedin.com/e/-kkb1ec-
On 08/02/11 11:17, Avi Kivity wrote:
On 08/01/2011 10:53 PM, Michael S. Tsirkin wrote:
>
>
> Just because a memory region becomes visible to the cpu is no reason
> to have a callback. From the device perspective, it can't tell that
> it happened.
BTW this is what qxl does, too, conceptually: on
On 08/02/2011 06:47 PM, Peter Maydell wrote:
I'm trying to update omap_gpmc to (a) support OMAP3/Beagle features
and (b) use sysbus/qdev rather than ad-hocery, and I'm having
difficulty figuring out how it fits into the new memory API.
Specifically, omap_gpmc lets you attach up to 8 devices to i
On Tue, Aug 2, 2011 at 2:45 PM, Shribman, Aidan wrote:
>> -Original Message-
>> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
>> Sent: Friday, July 08, 2011 12:07 AM
>> To: Shribman, Aidan
>> Cc: qemu-devel@nongnu.org; Anthony Liguori
>> Subject: Re: [PATCH v2] XBRLE page delta compres
On 29/07/2011 16:36, Anthony Liguori wrote:
> On 07/25/2011 03:29 AM, TeLeMan wrote:
>> The breakage was introduced by the commit
>> 13661089810d3e59931f3e80d7cb541b99af7071
>>
>> Signed-off-by: TeLeMan
>
> Applied. Thanks.
>
I think this patch should be applied in stable-0.15.
Regards,
--
I'm trying to update omap_gpmc to (a) support OMAP3/Beagle features
and (b) use sysbus/qdev rather than ad-hocery, and I'm having
difficulty figuring out how it fits into the new memory API.
Specifically, omap_gpmc lets you attach up to 8 devices to its chip
selects, and has registers which specif
On 08/02/2011 02:23 AM, Avi Kivity wrote:
>> +const MemoryRegionOps alpha_pci_bw_io_ops = {
>> +.read = bw_io_read,
>> +.write = bw_io_write,
>> +.endianness = DEVICE_LITTLE_ENDIAN,
>> +.impl = {
>> +.min_access_size = 1,
>> +.max_access_size = 4,
>> +},
>> +};
>
Am 02.08.2011 17:29, schrieb Frediano Ziglio:
>>> - L2 allocation can be done with relative data (this is not easy to do
>>> with current code)
>>
>> What do you mean by that?
>>
>
> Let's take an example. By allocation I mean give a position to
> data/l2/refcount_table. Usually you cannot update/
On Fri, Jul 29, 2011 at 10:40:45PM +0200, Stefan Weil wrote:
> With vhost_net="" (most non-Linux hosts), configure prints an
> error message:
>
> test: 2551: =: unexpected operator
>
> Fix this and similar code by adding the missing "".
>
> Cc: Wolfgang Mauerer
> Cc: Stefan Hajnoczi
> Signed-o
2011/8/2 Kevin Wolf :
> Am 02.08.2011 16:30, schrieb Frediano Ziglio:
>> Hi,
>> I spent some time trying to find a way to speed up qcow2 performance
>> on allocation and snapshot so I branch from kevin/coroutine-block
>> branch a qcow2x branch. Currently it just write using different
>> algorithm
Am 02.08.2011 16:55, schrieb Frediano Ziglio:
> 2011/8/2 Kevin Wolf :
>> Am 02.08.2011 16:23, schrieb Avi Kivity:
>>> On 07/26/2011 02:48 PM, Kevin Wolf wrote:
Depends on Stefan's latest coroutine patches. This series makes qcow and
qcow2
take advantage of the new coroutine infrastr
Am 02.08.2011 16:30, schrieb Frediano Ziglio:
> Hi,
> I spent some time trying to find a way to speed up qcow2 performance
> on allocation and snapshot so I branch from kevin/coroutine-block
> branch a qcow2x branch. Currently it just write using different
> algorithm (that is is fully compatible
On 08/02/2011 09:01 AM, Alexander Graf wrote:
On 02.08.2011, at 15:45, Shribman, Aidan wrote:
Subject: [PATCH v3] XBZRLE delta for live migration of large memory apps
From: Aidan Shribman
By using XBZRLE (Xor Binary Zero Run-Length-Encoding) we can reduce VM downtime
and total live-migration
On 08/02/2011 05:50 PM, Kevin Wolf wrote:
Am 02.08.2011 16:23, schrieb Avi Kivity:
> On 07/26/2011 02:48 PM, Kevin Wolf wrote:
>> Depends on Stefan's latest coroutine patches. This series makes qcow and
qcow2
>> take advantage of the new coroutine infrastructure. Both formats used
>> synchro
On 08/02/2011 09:50 AM, Kevin Wolf wrote:
Am 02.08.2011 16:23, schrieb Avi Kivity:
On 07/26/2011 02:48 PM, Kevin Wolf wrote:
Depends on Stefan's latest coroutine patches. This series makes qcow and qcow2
take advantage of the new coroutine infrastructure. Both formats used
synchronous operation
2011/8/2 Kevin Wolf :
> Am 02.08.2011 16:23, schrieb Avi Kivity:
>> On 07/26/2011 02:48 PM, Kevin Wolf wrote:
>>> Depends on Stefan's latest coroutine patches. This series makes qcow and
>>> qcow2
>>> take advantage of the new coroutine infrastructure. Both formats used
>>> synchronous operations
On 08/01/2011 09:26 PM, Anthony PERARD wrote:
Previously, the address space soft limit was set mcache_max_size. So,
before the mcache_max_size was reached by the mapcache, QEMU was killed
for overuse of the virtual address space.
This patch fix that by setting the soft limit to mcache_max_size +
Am 02.08.2011 16:23, schrieb Avi Kivity:
> On 07/26/2011 02:48 PM, Kevin Wolf wrote:
>> Depends on Stefan's latest coroutine patches. This series makes qcow and
>> qcow2
>> take advantage of the new coroutine infrastructure. Both formats used
>> synchronous operations for accessing their metadata
On 08/02/2011 04:01 PM, Alexander Graf wrote:
Of course that would mean that a block is no longer the size of a block:).
Is a block always the size of a page?
Paolo
Seems to only crash the first time qemu is started after booting the host
machine.
After the first crash, qemu will run solid for days if the host machine is not
rebooted.
If I have an opportunity, I'll test if it also crashes after first start when
kvm and/or kvm_intel modules are unloaded and
Hi,
I spent some time trying to find a way to speed up qcow2 performance
on allocation and snapshot so I branch from kevin/coroutine-block
branch a qcow2x branch. Currently it just write using different
algorithm (that is is fully compatible with qcow2, there is not
ICountAsZero(TM) method :) ).
On 07/26/2011 02:48 PM, Kevin Wolf wrote:
Depends on Stefan's latest coroutine patches. This series makes qcow and qcow2
take advantage of the new coroutine infrastructure. Both formats used
synchronous operations for accessing their metadata and blocked the guest CPU
during that time. With corou
Do not allocate TCG-only resources like the translation buffer when
running over KVM or XEN. Saves a "few" bytes in the qemu address space
and is also conceptually cleaner.
Signed-off-by: Jan Kiszka
---
Note: Only tested on x86.
bsd-user/main.c |3 ++-
darwin-user/main.c|4 ++
On 02.08.2011, at 15:45, Shribman, Aidan wrote:
> Subject: [PATCH v3] XBZRLE delta for live migration of large memory apps
> From: Aidan Shribman
>
> By using XBZRLE (Xor Binary Zero Run-Length-Encoding) we can reduce VM
> downtime
> and total live-migration time for VMs running memory write i
If we're already in a coroutine, there is no reason to use the synchronous
version of block layer functions when a coroutine one exists. This makes
bdrv_read/write/flush use bdrv_co_* when used inside a coroutine.
Signed-off-by: Kevin Wolf
---
v2:
- Avoid endless recursion when we're in a corout
Subject: [PATCH v3] XBZRLE delta for live migration of large memory apps
From: Aidan Shribman
By using XBZRLE (Xor Binary Zero Run-Length-Encoding) we can reduce VM downtime
and total live-migration time for VMs running memory write intensive workloads
typical of large enterprise applications suc
> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> Sent: Thursday, July 07, 2011 11:23 AM
> To: Shribman, Aidan
> Cc: qemu-devel@nongnu.org; Anthony Liguori
> Subject: Re: [PATCH v2] XBRLE page delta compression for live
> migration of large memory apps
>
> Any thoughts on reducing the overh
> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@gmail.com]
> Sent: Friday, July 08, 2011 12:07 AM
> To: Shribman, Aidan
> Cc: qemu-devel@nongnu.org; Anthony Liguori
> Subject: Re: [PATCH v2] XBRLE page delta compression for live
> migration of large memory apps
>
>
> Out o
Am 26.07.2011 11:21, schrieb Stefan Hajnoczi:
> To run automated tests for coroutines:
>
> make test-coroutine
> ./test-coroutine
>
> On success the program terminates with exit status 0. On failure an
> error message is written to stderr and the program exits with exit
> status 1.
>
> Sign
On 13 May 2011 23:08, Mathieu Sonet wrote:
[PL041/AACI patches]
I apologise for the exceedingly delayed review here.
So to start with, I tested this patch with the vexpress-a9
board (by adding the one line to add a pl041 to it) and it
works, which is really cool.
A minor note on patch formattin
This patch adds a simple ARP table in Slirp and also adds handling of
gratuitous ARP requests.
Signed-off-by: Fabien Chouteau
---
Makefile.objs |2 +-
slirp/arp_table.c | 71 +
slirp/bootp.c | 21 +--
slirp/slirp.c
On 2011-08-02 14:13, Anthony PERARD wrote:
> On Tue, Aug 2, 2011 at 11:49, Jan Kiszka wrote:
>>> The same applies to kvm, please generalize.
>>
>> Actually, qemu-kvm avoids this overhead today by making code_gen_alloc
>> return immediately when kvm is on. Also not very beautiful.
>>
>> Can't we si
On 08/01/2011 10:22 PM, Richard Henderson wrote:
On 07/31/2011 10:57 AM, Avi Kivity wrote:
> +pci_register_bar_region(dev, 3, PCI_BASE_ADDRESS_SPACE_IO,
> +&d->cmd646_bar[2].cmd);
Typo: cmd646_bar[1].
Thanks, fixed.
--
error compiling committee.c: too many arguments to function
On Tue, Aug 02, 2011 at 11:33:09AM +0200, Bjørn Mork wrote:
> "Kevin O'Connor" writes:
> > Also, it's possible the code could try to use the f-segment if there
> > are less than say 16 cpus and use high memory when more cpus are
> > present.
>
> How about a variant over the last suggestion: Don't
On 08/02/2011 12:34 PM, Michael S. Tsirkin wrote:
On Tue, Aug 02, 2011 at 12:17:06PM +0300, Avi Kivity wrote:
> On 08/01/2011 10:53 PM, Michael S. Tsirkin wrote:
> >>
> >>
> >> Just because a memory region becomes visible to the cpu is no reason
> >> to have a callback. From the device
On Tue, Aug 2, 2011 at 11:49, Jan Kiszka wrote:
>> The same applies to kvm, please generalize.
>
> Actually, qemu-kvm avoids this overhead today by making code_gen_alloc
> return immediately when kvm is on. Also not very beautiful.
>
> Can't we simply skip cpu_exec_init_all for any accel != TCG, e
Am 26.07.2011 13:49, schrieb Kevin Wolf:
> In order to be able to call bdrv_co_readv/writev for drivers that don't
> implement the functions natively, add an emulation that uses the AIO functions
> to implement them.
>
> Signed-off-by: Kevin Wolf
> ---
> block.c | 84 +
Hi Anthony,
This is a simple fix to make sure the permissions of data files installed
with the make libcacard-install rule are not executable.
Please pull,
Alon
The following changes since commit 927d721777e73339f73719f36eaf400ab641366c:
microblaze: Add missing call to qemu_init_vcpu. (2011-0
Since the next patch will move VMState declarations for ptimers out
of hw/hw.h, prepare a place for them.
Signed-off-by: Paolo Bonzini
---
hw/arm_timer.c|1 +
hw/etraxfs_timer.c|1 +
hw/grlib_apbuart.c|1 +
hw/grlib_gptimer.c|1 +
hw/lan9118.c |1
*** BLURB HERE ***
Paolo Bonzini (2):
ptimer: move declarations to ptimer.h
vmstate: extract declarations out of hw/hw.h
hw/arm_timer.c|1 +
hw/etraxfs_timer.c|1 +
hw/grlib_apbuart.c|1 +
hw/grlib_gptimer.c|1 +
hw/hw.h | 862 +-
On Wed, Jul 27, 2011 at 10:27 AM, Fam Zheng wrote:
> @@ -863,6 +884,9 @@ static int vmdk_write_extent(VmdkExtent *extent, int64_t
> cluster_offset,
> }
> ret = 0;
> out:
> + if (data) {
> + qemu_free(data);
> + }
qemu_free(NULL) is a nop, you don't need the if statement. J
On Wed, Jul 27, 2011 at 10:27 AM, Fam Zheng wrote:
> @@ -415,6 +428,9 @@ static int vmdk_open_vmdk4(BlockDriverState *bs,
> l1_size,
> le32_to_cpu(header.num_gtes_per_gte),
> le64_to_cpu(header.granularity));
> + exte
On 2011-08-01 21:57, Jan Kiszka wrote:
> On 2011-08-01 21:26, Anthony PERARD wrote:
>> The code_gen_buffer is not use by Xen and can be really big (several
>> GB). Even if the host RAM is not used, this buffer just burn the address
>> space of the QEMU process.
>>
>> So to "avoid" this allocation,
1 - 100 of 117 matches
Mail list logo
