On 08/01/2011 11:00 PM, Umesh Deshpande wrote:
I kept this in migration.c to call qemu_savevm_state_begin. (The way it
is done currently. i.e. to keep access to FdMigrationState in migration.c)
Calling it from buffered_file.c would be inconsistent in that sense. or
we will have to call it from
[ Adding back qemu-devel to CC ]
Am 02.08.2011 06:27, schrieb Devin Nakamura:
> On Mon, Aug 1, 2011 at 10:32 AM, Kevin Wolf wrote:
>> Am 29.07.2011 06:49, schrieb Devin Nakamura:
>>> Signed-off-by: Devin Nakamura
>>> ---
>>> block/qcow2-cluster.c | 49
>>>
On Fri, Jul 29, 2011 at 12:49:31AM -0400, Devin Nakamura wrote:
> +/**
> + * Gets a mapping in the image file.
> + *
> + * The function starts searching for a mapping at
> + * starting_guest_offset = guest_offset + contiguous_bytes
> + *
> + * @param bs[in]
On Fri, Jul 29, 2011 at 12:49:33AM -0400, Devin Nakamura wrote:
> +int bdrv_open_conversion_target(BlockDriverState **bs, BlockDriverState
> *file,
> +BlockConversionOptions *drv_options,
> +QEMUOptionParameter *usr_options,
> +
On Fri, Jul 29, 2011 at 12:49:34AM -0400, Devin Nakamura wrote:
> +/**
> + * Gets a mapping from an offset in the image to an offset within a file
> + *
> + * All offsets are in bytes. Functions starts its search at offset
> host_offset
> + * + count (offset within the image, not the file offset)
On Fri, Jul 29, 2011 at 12:49:39AM -0400, Devin Nakamura wrote:
> +static int bdrv_qed_get_mapping(BlockDriverState *bs, uint64_t *guest_offset,
> +uint64_t *host_offset,
> +uint64_t *contiguous_bytes)
> +{
> +BDRVQEDState *s = bs-
On Tue, Aug 2, 2011 at 5:03 AM, wrote:
> The Buildbot has detected a new failure on builder
> trivial-patches_i386_debian_5_0 while building qemu.
> Full details are available at:
> http://buildbot.b1-systems.de/qemu/builders/trivial-patches_i386_debian_5_0/builds/52
>
> Buildbot URL: http://bu
On 2 August 2011 03:36, Anthony Liguori wrote:
> diff --git a/scripts/aliases.txt b/scripts/aliases.txt
> new file mode 100644
> index 000..aadea25
> --- /dev/null
> +++ b/scripts/aliases.txt
> @@ -0,0 +1,18 @@
> +andrew.zaborow...@intel.com: bal...@zabor.org
> +ed...@axis.com: edgar.igles...@
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 config writes, it peeks
at the ba
Am 02.08.2011 10:56, schrieb Stefan Hajnoczi:
>> @@ -263,4 +345,10 @@ static inline unsigned int
>> get_physical_block_exp(BlockConf *conf)
>> DEFINE_PROP_UINT32("discard_granularity", _state, \
>> _conf.discard_granularity, 0)
>>
>> +struct BlockConversionOptions {
On 08/02/2011 12:23 AM, Richard Henderson wrote:
+
+/* PCI IO reads/writes, to byte-word addressable memory. */
+/* ??? Doesn't handle multiple PCI busses. */
+
+static uint64_t bw_io_read(void *opaque, target_phys_addr_t addr, unsigned
size)
+{
+switch (size) {
+case 1:
+retur
"Kevin O'Connor" writes:
> On Mon, Aug 01, 2011 at 03:49:11PM +0200, Bjørn Mork wrote:
>> I just confirmed the issue running
>>
>> "JUNOS 11.1R3.5 built 2011-06-25 00:17:21 UTC"
>>
>> which is as new as it officially gets at the moment.
> [...]
>> Also confirmed that 11.1R3.5 is working with Se
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 perspective, it can't tell that
> >> it happened.
> >
> >B
On 01/08/2011 22:16, Jan Kiszka wrote:
> On 2011-08-01 18:18, Fabien Chouteau wrote:
>> 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 | 72
>> +++
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 Capitulino
> > > wrote:
> > > > This function should be used when the VM is not
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 suffer the source identifier problem, but they do often
> share an in
On Wed, Jul 27, 2011 at 10:27 AM, Fam Zheng wrote:
> Add twoGbMaxExtentSparse support. Only opening code is changed.
>
> Signed-off-by: Fam Zheng
> ---
> block/vmdk.c | 124
> --
> 1 files changed, 77 insertions(+), 47 deletions(-)
>
> di
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,
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 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
*** 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 +-
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
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
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 +
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
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 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/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 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
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 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
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
> -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
> 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
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
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
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
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 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
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 :) ).
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
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
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/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 +
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/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
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: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
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
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
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
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
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 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,
>> +},
>> +};
>
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 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,
--
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 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 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
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 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
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 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
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 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 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 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 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 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, 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 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, 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 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 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 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 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 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 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
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
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
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
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
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 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
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/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 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 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/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 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 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 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 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 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/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 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/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 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
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: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
1 - 100 of 117 matches
Mail list logo
