On 27.06.2016 22:29, Samuel Thibault wrote:
> Hello,
>
> Thomas Huth, on Sun 26 Jun 2016 10:04:02 +0200, wrote:
>> Provide basic support for stateless DHCPv6 (see RFC 3736) so
>> that guests can also automatically boot via IPv6 with SLIRP
>> (for IPv6 network booting, see RFC 5970 for details).
>
On Mon, Jun 27, 2016 at 05:09:38PM +0200, Cornelia Huck wrote:
> On Mon, 27 Jun 2016 11:44:47 +0200
> Peter Lieven wrote:
>
> > Hi, with the above patch applied:
> >
> > commit 9f06e71a567ba5ee8b727e65a2d5347fd331d2aa
> > Author: Cornelia Huck
> > Date: Fri Jun 10 11:04:12 2016 +0200
> >
> >
Thomas Huth, on Tue 28 Jun 2016 09:01:50 +0200, wrote:
> The options in the DHCPv6 packet do not have any alignment
> requirement, so the can also start at uneven addresses.
Aow, OK :/
> So I'd like to keep the current code, but I can add some more comments
> if you think that helps to understand
On Sun, Jun 26, 2016 at 03:27:50PM +0200, Jan Kiszka wrote:
> On 2016-06-26 03:48, Peter Xu wrote:
> > On Sat, Jun 25, 2016 at 05:18:40PM +0200, Jan Kiszka wrote:
> >> On 2016-06-25 15:18, Peter Xu wrote:
> >>> On Sat, Jun 25, 2016 at 10:08:10AM +0200, Jan Kiszka wrote:
> >
> > [...]
> >
> >>> I
On Tue, 28 Jun 2016 08:22:05 +0200
Peter Lieven wrote:
> Am 27.06.2016 um 17:09 schrieb Cornelia Huck:
> > On Mon, 27 Jun 2016 11:44:47 +0200
> > Peter Lieven wrote:
> >
> >> Hi, with the above patch applied:
> >>
> >> commit 9f06e71a567ba5ee8b727e65a2d5347fd331d2aa
> >> Author: Cornelia Huck
>
Hi Bharata,
there seems to be a regression with current QEMU master: The pseries
machine does not work with older 64-bit ppc CPUs anymore. With QEMU
2.6.0, it is possible to run:
qemu-system-ppc64 -nographic -M pseries -cpu 970
or
qemu-system-ppc64 -nographic -M pseries -cpu POWER5+
but wi
On 2016年06月28日 14:48, Michael S. Tsirkin wrote:
On Thu, Jun 23, 2016 at 12:46:46AM +0800, Wei Xu wrote:
On 2016年06月22日 23:39, Eric Blake wrote:
On 06/22/2016 09:25 AM, Wei Xu wrote:
There have been comments on this patch, but i forgot adding this patch to
the list, just forward it again.
When
On Tue, 28 Jun 2016 10:03:21 +0300
"Michael S. Tsirkin" wrote:
> I notice cleanup is a bit weird:
>
> virtio_queue_set_host_notifier_fd_handler(vq, false, false);
> k->ioeventfd_assign(proxy, notifier, n, assign);
> event_notifier_cleanup(notifier);
>
> I think virtio_qu
On Tue, 28 Jun 2016 00:12:03 +0200
Thomas Huth wrote:
> event_notifier_init() can fail in real life, for example when there
> are not enough open file handles available (EMFILE) when using a lot
> of devices. So instead of leaving the average user with a cryptic
> error number only, print out a p
On Fri, 24 Jun 2016 10:33:10 -0600
Eric Blake wrote:
> On 06/24/2016 10:05 AM, Igor Mammedov wrote:
> > custom apic-id setter/getter doesn't do any property specific
> > checks anymorer, so clean it up and use more compact static
>
> s/anymorer/anymore/
Thanks,
I'll fix it on respin.
>
> > p
Am 28.06.2016 um 09:42 schrieb Cornelia Huck:
On Tue, 28 Jun 2016 10:03:21 +0300
"Michael S. Tsirkin" wrote:
I notice cleanup is a bit weird:
virtio_queue_set_host_notifier_fd_handler(vq, false, false);
k->ioeventfd_assign(proxy, notifier, n, assign);
event_notifier
On 20/05/2016 10:20, Xiao Guangrong wrote:
> +if (size <= nvdimm->label_size) {
> +HostMemoryBackend *hostmem = dimm->hostmem;
> +char *path = object_get_canonical_path_component(OBJECT(hostmem));
> +
> +error_setg(errp, "the size of memdev %s (0x%" PRIx64 ") is too"
>
Public bug reported:
This is tested using qemu 2.4.1, but it looks like the code
qemu/hw/ppc/e500.c has not changed since. This looks like the source of
the problem:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=3812c71ffaa2cf733c3087792b859fef30b7545f
What works:
--
Basic invocation q
Eric Blake writes:
> On 06/14/2016 07:46 AM, Eric Blake wrote:
>> On 06/14/2016 07:24 AM, Markus Armbruster wrote:
>>> Eric Blake writes:
>>>
We were previously enforcing that all flat union branches were
found in the corresponding enum, but not that all enum values
were covered b
On Tue, Jun 28, 2016 at 09:29:33AM +0200, Thomas Huth wrote:
>
> Hi Bharata,
>
> there seems to be a regression with current QEMU master: The pseries
> machine does not work with older 64-bit ppc CPUs anymore. With QEMU
> 2.6.0, it is possible to run:
>
> qemu-system-ppc64 -nographic -M pserie
On Tue, 28 Jun 2016 09:47:01 +0200
Peter Lieven wrote:
> Am 28.06.2016 um 09:42 schrieb Cornelia Huck:
> > On Tue, 28 Jun 2016 10:03:21 +0300
> > "Michael S. Tsirkin" wrote:
> >
> >> I notice cleanup is a bit weird:
> >>
> >> virtio_queue_set_host_notifier_fd_handler(vq, false, false);
On Tue, Jun 28, 2016 at 04:24:22PM +1000, David Gibson wrote:
> On Tue, Jun 28, 2016 at 07:24:16AM +0200, Greg Kurz wrote:
> > On Tue, 28 Jun 2016 12:55:07 +1000
> > David Gibson wrote:
> >
> > > On Mon, Jun 27, 2016 at 06:28:15PM +0200, Greg Kurz wrote:
> > > > This fixes a potential QEMU crash
On 06/28/2016 05:56 AM, David Gibson wrote:
On Mon, Jun 27, 2016 at 06:38:31PM +0300, Marcel Apfelbaum wrote:
Mac99's PCI root bus is not part of a host bridge,
realize it manually.
Um.. how did this ever work?
Well, the only thing the PCI bus realize does is
to register the VM migration sta
On 27/06/2016 18:43, Cédric Le Goater wrote:
> +args = g_strdup_printf("-M 256 -machine palmetto-bmc "
Also you want "-m 256". This is not failing because the "256" machine
type is overwritten by "palmetto-bmc".
Paolo
> + "-drive file=%s,format=raw,if=mtd",
> +
On 27/06/2016 18:43, Cédric Le Goater wrote:
> check-qtest-arm-y = tests/ds1338-test$(EXESUF)
> +check-qtest-arm-y = tests/m25p80-test$(EXESUF)
This should be a "+=".
Paolo
> gcov-files-arm-y += hw/misc/tmp105.c
> check-qtest-arm-y += tests/virtio-blk-test$(EXESUF)
On 27 June 2016 at 19:32, Paolo Bonzini wrote:
>
>
> On 17/06/2016 21:46, Richard Henderson wrote:
>> Using gcc 6.1 for alpha-linux-user target we see the following build error:
>>
>> .../target-alpha/translate.c: In function ‘in_superpage’:
>> .../target-alpha/translate.c:454:52: error: self-comp
Eric Blake writes:
> On 06/16/2016 06:25 AM, Markus Armbruster wrote:
>> Markus Armbruster writes:
>>
>>> Eric Blake writes:
>>>
When an event has data that is not boxed, we are exposing all of
its members alongside our local variables. So far, we haven't
hit a collision, but i
Eric Blake writes:
> On 06/27/2016 02:50 AM, Markus Armbruster wrote:
>
>> With an ugly Perl script, of course %-/
>>
>
>> I'm afraid my script and its usage is too brittle to be of much use
>> later on. I attach it anyway.
>
> A zero byte file map-include-to-header.pl~. Infinite compression :
On 06/28/2016 05:57 AM, David Gibson wrote:
On Mon, Jun 27, 2016 at 06:38:35PM +0300, Marcel Apfelbaum wrote:
Since iommu devices can be created with '-device' there is
no need to keep iommu as machine and mch property.
Doesn't this break backwards compatibility?
Hi David,
Intel IOMMU was
On 21 June 2016 at 18:09, Peter Maydell wrote:
> This set of patches is a development based on the ones from Vijaya:
> the general idea is similar but I have tried to improve the interface
> for defining the page size a bit. I've also tweaked patches 2 and 3
> to address code review comments.
>
On Tue, 28 Jun 2016 09:47:01 +0200
Peter Lieven wrote:
> The problem goes away, but its horribly slow. Maybe the lost notifications
> you were thinking off.
I have the following patch (works for me on ccw as well). I'm worried
about the slowness you're seeing, though. Is this just with an iscsi
On Tue 28 Jun 2016 03:47:47 AM CEST, Fam Zheng wrote:
> The qcrypto_hash_supports is actually a static check, determined at
> compile time. Follow the block-job-$(CONFIG_FOO) convention for
> consistency.
>
> Signed-off-by: Fam Zheng
Oh, so we didn't see this in e94867e :-)
Reviewed-by: Alber
Peter Maydell writes:
> On 27 June 2016 at 09:50, Markus Armbruster wrote:
>> To spice up things, we
>> also name a few of our headers just like system headers we use
>> elsewhere, e.g. "util.h" in net/ vs. in util/qemu-openpty.c.
>
> That would be nice to fix at some point I think, it's pretty
Peter Maydell writes:
> On 27 June 2016 at 07:34, Markus Armbruster wrote:
>> Peter Maydell writes:
>>> This is third-party code. We're not going to change it, so
>>> we should avoid scanning it rather than adding tags which
>>> will get lost next time we do an update to a new upstream
>>> vers
replace mainly useless exit(1) on fatal error path with
abort(), so that it would be possible to generate core
dump, that could be used to analyse cause of problem.
Signed-off-by: Igor Mammedov
---
hw/virtio/virtio.c | 24
1 file changed, 12 insertions(+), 12 deletions(-
On Tue, Jun 28, 2016 at 8:41 AM, Auger Eric wrote:
> Dear all,
>
> On 24/11/2015 11:13, Pavel Fedin wrote:
>> This series introduces support for in-kernel GICv3 ITS emulation.
>> It is based on kernel API which is not released yet, therefore i post
>> it as an RFC.
>>
>> Kernel patch sets which im
On 06/28/2016 10:03 AM, Paolo Bonzini wrote:
>
>
> On 27/06/2016 18:43, Cédric Le Goater wrote:
>> +args = g_strdup_printf("-M 256 -machine palmetto-bmc "
>
> Also you want "-m 256". This is not failing because the "256" machine
> type is overwritten by "palmetto-bmc".
I should have seen t
On 06/28/2016 10:01 AM, Paolo Bonzini wrote:
>
>
> On 27/06/2016 18:43, Cédric Le Goater wrote:
>> check-qtest-arm-y = tests/ds1338-test$(EXESUF)
>> +check-qtest-arm-y = tests/m25p80-test$(EXESUF)
>
> This should be a "+=".
OK. I will fix the above line also then :
check-qtest-arm-y =
On 28 June 2016 at 09:19, Markus Armbruster wrote:
> Peter Maydell writes:
>
>> On 27 June 2016 at 07:34, Markus Armbruster wrote:
>>> Peter Maydell writes:
This is third-party code. We're not going to change it, so
we should avoid scanning it rather than adding tags which
will g
On 28 June 2016 at 09:32, Cédric Le Goater wrote:
> On 06/28/2016 10:01 AM, Paolo Bonzini wrote:
>>
>>
>> On 27/06/2016 18:43, Cédric Le Goater wrote:
>>> check-qtest-arm-y = tests/ds1338-test$(EXESUF)
>>> +check-qtest-arm-y = tests/m25p80-test$(EXESUF)
>>
>> This should be a "+=".
>
> OK. I will
On 28 June 2016 at 00:05, Andrew Jeffery wrote:
> On Mon, 2016-06-27 at 17:53 -0400, Pranith Kumar wrote:
>> Tracing configurations error out currently as follows:
>>
>> /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c: In function
>> ‘aspeed_scu_read’:
>> /home/travis/build/pranith/qemu/hw/m
On 27 June 2016 at 20:24, John Snow wrote:
> The following changes since commit 14e60aaece20a1cfc059a69f6491b0899f9257a8:
>
> hw/net/e1000: Don't use *_to_cpup() (2016-06-27 16:39:56 +0100)
>
> are available in the git repository at:
>
> https://github.com/jnsnow/qemu.git tags/ide-pull-request
** Tags added: ppc
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1596832
Title:
e500 -bios/-kernel broken with big images
Status in QEMU:
New
Bug description:
This is tested using qemu 2.4.1,
When doing a read-modify-write cycle, QEMU uses the iovec after returning
from blk_aio_pwritev. m25p80 puts the iovec on the stack of blk_aio_pwritev's
caller, which causes trouble in this case. This has been a problem
since commit 243e6f6 ("m25p80: Switch to byte-based block access",
2016-05-12)
s->cur_addr can be made to point outside s->storage, either by
writing a value >= 128 to s->ear (because s->ear * MAX_3BYTES_SIZE
is a signed integer and sign-extends into the 64-bit cur_addr),
or just by writing an address beyond the size of the flash being
emulated. Avoid the sign extension to m
The first causes a failure in the new qtest. The second fixes a possible
out-of-bounds access, and the third fixes again half of the same
out-of-bounds access.
Paolo Bonzini (3):
m25p80: do not put iovec on the stack
m25p80: avoid out of bounds accesses
m25p80: change cur_addr to 32 bit int
The maximum amount of storage that can be addressed by the m25p80 command
set is 4 GiB. However, cur_addr is currently a 64-bit integer. To avoid
further problems related to sign extension of signed 32-bit integer
expressions, change cur_addr to a 32 bit integer. Preserve migration
format by add
Sascha Silbe writes:
> Dear Paolo,
>
> Paolo Bonzini writes:
>
>>> After applying your series on top of f12103af and running "./configure"
>>> in a clean working directory, I get the following errors for "make
>>> check-source":
>>>
>>> $ make check-source
>>> egrep: config-host.h: No such file
On Fri, Jun 24, 2016 at 3:46 PM, Kevin Wolf wrote:
>> diff --git a/block/linux-aio.c b/block/linux-aio.c
>> index e468960..fe7cece 100644
>> --- a/block/linux-aio.c
>> +++ b/block/linux-aio.c
>> @@ -149,8 +149,6 @@ static void qemu_laio_completion_bh(void *opaque)
>> if (!s->io_q.plugged && !
On 06/28/2016 10:34 AM, Peter Maydell wrote:
> On 28 June 2016 at 09:32, Cédric Le Goater wrote:
>> On 06/28/2016 10:01 AM, Paolo Bonzini wrote:
>>>
>>>
>>> On 27/06/2016 18:43, Cédric Le Goater wrote:
check-qtest-arm-y = tests/ds1338-test$(EXESUF)
+check-qtest-arm-y = tests/m25p80-test
Potential fix posted
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07693.html
If you are able to test with this patch any feedback would be welcome.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.n
Emilio G Cota writes:
[...]
> - What to do when atomic ops are used on something other than RAM?
> Should we have a "slow path" that is not atomic for these cases, or
> it's OK to assume code is bogus? For now, I just wrote XXX.
[...]
You mean, for example, on I/O space? In these cases, it dep
On 06/28/2016 10:39 AM, Paolo Bonzini wrote:
> When doing a read-modify-write cycle, QEMU uses the iovec after returning
> from blk_aio_pwritev. m25p80 puts the iovec on the stack of blk_aio_pwritev's
> caller, which causes trouble in this case. This has been a problem
> since commit 243e6f6 ("m2
evaluation with the recently introduced maximum stack size monitoring revealed
that the actual used stack size was never above 4kB so allocating 1MB stack
for each coroutine is a lot of wasted memory. So reduce the stack size to
64kB which should still give enough head room.
Signed-off-by: Peter L
the VncState is approx. 85kB
Signed-off-by: Peter Lieven
---
ui/vnc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 95e4db7..bf87135 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -45,6 +45,7 @@
#include "crypto/tlscredsx509.h"
#include "qom/object
I recently found that Qemu is using several hundred megabytes of RSS memory
more than older versions such as Qemu 2.2.0. So I started tracing
memory allocation and found 2 major reasons for this.
1) We changed the qemu coroutine pool to have a per thread and a global release
pool. The choosen p
coroutine-ucontext currently allocates stack memory from heap as on most
systems the
stack size lays below the threshold for mmapping memory. This patch forces
mmaping
of stacks to avoid large holes on the heap when a coroutine is deleted. It
additionally
allows us for adding a guard page at the
Signed-off-by: Peter Lieven
---
include/qom/object.h | 1 +
qom/object.c | 20 +---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/include/qom/object.h b/include/qom/object.h
index 2f8ac47..c612f3a 100644
--- a/include/qom/object.h
+++ b/include/qom/objec
Hi,
it seems we broke the block/gluster.c functionality with a recent patch
in upstream Gluster. In order to prevent this from happening in the
future, I would like to setup a Jenkins job that installs a plan CentOS
with its version of QEMU, and nightly builds of upstream Gluster.
Getting a notifi
this was causing serious framentation in conjunction with the
subpages since RCU was introduced. The node space was allocated
at approx 32kB then reallocted to approx 75kB and this a few hundred
times at startup. And thanks to RCU the freeing was delayed.
Signed-off-by: Peter Lieven
---
exec.c |
this adds a debug configure switch to enable monitoring of the
maximum used stack size by all coroutines.
Signed-off-by: Peter Lieven
---
configure | 18 ++
util/coroutine-ucontext.c | 40
2 files changed, 58 insertions(+)
a classic use for mmap here.
Signed-off-by: Peter Lieven
---
hw/core/loader.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/hw/core/loader.c b/hw/core/loader.c
index 53e0e41..f217edc 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -55,6 +55,7 @@
#i
the current coroutine freelist implementation has 2 kinds of pools.
One shared release pool between all threads and additionally one
allocation pool per thread. The release pool is especially necessary
if the coroutine is created in a different thread than it is released.
This is e.g. the case if a
this struct is approx 75kB
Signed-off-by: Peter Lieven
---
qapi/qmp-input-visitor.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index aea90a1..b6f5dfd 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visit
for the calculation of number of subcolors of each subrect a new palette was
allocated,
memset to zero and then destroyed. Use a static palette for this instead.
Signed-off-by: Peter Lieven
---
ui/vnc-enc-tight.c | 21 ++---
ui/vnc.h | 1 +
2 files changed, 11 inserti
Signed-off-by: Peter Lieven
---
include/qemu/mmap-alloc.h | 6 ++
util/mmap-alloc.c | 17 +
2 files changed, 23 insertions(+)
diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
index 0899b2f..a457721 100644
--- a/include/qemu/mmap-alloc.h
+++ b/includ
On Tue, Jun 28, 2016 at 09:48:10AM +0200, Paolo Bonzini wrote:
>
>
> On 20/05/2016 10:20, Xiao Guangrong wrote:
> > +if (size <= nvdimm->label_size) {
> > +HostMemoryBackend *hostmem = dimm->hostmem;
> > +char *path = object_get_canonical_path_component(OBJECT(hostmem));
> > +
On 06/28/2016 10:39 AM, Paolo Bonzini wrote:
> s->cur_addr can be made to point outside s->storage, either by
> writing a value >= 128 to s->ear (because s->ear * MAX_3BYTES_SIZE
> is a signed integer and sign-extends into the 64-bit cur_addr),
> or just by writing an address beyond the size of the
a VirtQueue is approx. 128kB in size.
Signed-off-by: Peter Lieven
---
hw/virtio/virtio.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 7ed06ea..bf4bc4a 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -20,6 +20,7
a lot of subpages are created and freed at startup, but RCU delays
the freeing so the heap gets fragmented.
Signed-off-by: Peter Lieven
---
exec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 0122ef7..1b7be2a 100644
--- a/exec.c
+++ b/exec.c
@@ -
On Tue, 28 Jun 2016 10:24:29 +0200
Igor Mammedov wrote:
> replace mainly useless exit(1) on fatal error path with
> abort(), so that it would be possible to generate core
> dump, that could be used to analyse cause of problem.
>
> Signed-off-by: Igor Mammedov
> ---
Makes sense indeed.
Acked-b
Signed-off-by: Peter Lieven
---
include/qemu/mmap-alloc.h | 1 +
util/mmap-alloc.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/include/qemu/mmap-alloc.h b/include/qemu/mmap-alloc.h
index a457721..935a907 100644
--- a/include/qemu/mmap-alloc.h
+++ b/include/qemu/mmap-
object_get_canonical_path_component() returns a heap-allocated string
that must be freed using g_free().
Reported-by: Paolo Bonzini
Signed-off-by: Stefan Hajnoczi
---
hw/mem/nvdimm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/hw/mem/nvdimm.c b/hw/mem/nvdimm.c
index 81896c0..7895805 100
the scratch pad is 256kB
Signed-off-by: Peter Lieven
---
hw/display/vmware_vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/display/vmware_vga.c b/hw/display/vmware_vga.c
index e51a05e..9942b2d 100644
--- a/hw/display/vmware_vga.c
+++ b/hw/display/vmware_vga.c
@@ -2
On Mon, Jun 27, 2016 at 06:42:33PM +0200, Paolo Bonzini wrote:
>
>
> On 27/06/2016 18:37, Stefan Hajnoczi wrote:
> > Commit ccb9dc10129954d0bcd7814298ed445e684d5a2a ("linux-aio: Cancel BH
> > if not needed") exposed a side-effect of scheduling the BH for nested
> > event loops. When io_getevents
On 06/28/2016 02:19 AM, John Snow wrote:
On 06/27/2016 10:47 AM, Denis V. Lunev wrote:
From: Evgeny Yakovlev
Due to changes in flush behaviour clean disks stopped generating
flush_to_disk events and IDE and AHCI tests that test flush commands
started to fail.
This change adds additional DMA
On 06/28/2016 10:39 AM, Paolo Bonzini wrote:
> The maximum amount of storage that can be addressed by the m25p80 command
> set is 4 GiB. However, cur_addr is currently a 64-bit integer. To avoid
> further problems related to sign extension of signed 32-bit integer
> expressions, change cur_addr t
On 06/28/2016 05:06 PM, Stefan Hajnoczi wrote:
object_get_canonical_path_component() returns a heap-allocated string
that must be freed using g_free().
Reviewed-by: Xiao Guangrong
Thanks for your fix and thank Paolo for the report.
On (Mon) 27 Jun 2016 [08:53:47], Dr. David Alan Gilbert wrote:
> * Amit Shah (amit.s...@redhat.com) wrote:
> > On (Tue) 21 Jun 2016 [20:13:54], Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > Hi,
> > > This series converts the outer most layer of virtio to
>
Am 28.06.2016 um 10:16 schrieb Cornelia Huck:
On Tue, 28 Jun 2016 09:47:01 +0200
Peter Lieven wrote:
The problem goes away, but its horribly slow. Maybe the lost notifications
you were thinking off.
I have the following patch (works for me on ccw as well). I'm worried
about the slowness you'r
Hi Stefan,
I am working on something to move PCI devices to data plane architecture.
Do you know any know reasons, as to why this was not tried before ?
Regards,
On Fri, Jun 24, 2016 at 3:45 PM, Stefan Hajnoczi wrote:
> On Thu, Jun 23, 2016 at 08:56:34PM +0530, Gaurav Sharma wrote:
> > Hi,
> >
* Peter Lieven (p...@kamp.de) wrote:
> this struct is approx 75kB
I wonder why it's so large.
The stack size in QmpInputVisitor; it's got a 1024 element stack
(QIV_STACK_SIZE) and I bet we never use anywhere near that.
But even then that's 1024 * a 3 pointer stack object, 24 bytes -
I don't see
Am 28.06.2016 um 11:29 schrieb Dr. David Alan Gilbert:
* Peter Lieven (p...@kamp.de) wrote:
this struct is approx 75kB
I wonder why it's so large.
The stack size in QmpInputVisitor; it's got a 1024 element stack
(QIV_STACK_SIZE) and I bet we never use anywhere near that.
But even then that's
On Tue, 28 Jun 2016 10:06:46 +0100
Stefan Hajnoczi wrote:
> object_get_canonical_path_component() returns a heap-allocated string
> that must be freed using g_free().
>
> Reported-by: Paolo Bonzini
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Igor Mammedov
> ---
> hw/mem/nvdimm.c | 1 +
>
On Mon, Jun 27, 2016 at 08:36:19PM +0200, Roman Penyaev wrote:
> On Jun 27, 2016 6:37 PM, "Stefan Hajnoczi" wrote:
> >
> > Commit ccb9dc10129954d0bcd7814298ed445e684d5a2a ("linux-aio: Cancel BH
> > if not needed") exposed a side-effect of scheduling the BH for nested
> > event loops. When io_gete
On 06/28/2016 04:27 AM, Fam Zheng wrote:
On Mon, 06/27 17:47, Denis V. Lunev wrote:
From: Evgeny Yakovlev
Some guests (win2008 server for example) do a lot of unnecessary
flushing when underlying media has not changed. This adds additional
overhead on host when calling fsync/fdatasync.
This c
On Mon, Jun 27, 2016 at 02:14:09PM +0200, Thomas Huth wrote:
> +function show_help {
> +echo "Usage:"
> +echo " -s : Start searching by this commit"
s/by/at/
> +echo " -e : End searching by this commit"
s/by/at/
> +echo " -c : Check if bugs are still open"
> +
On 27 June 2016 at 22:53, Pranith Kumar wrote:
> Tracing configurations error out currently as follows:
>
> /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c: In function
> ‘aspeed_scu_read’:
> /home/travis/build/pranith/qemu/hw/misc/aspeed_scu.c:130:9: error: implicit
> declaration of functi
>
> qboot does basically four things: 1) relocate from ROM to 0xf; 2)
> initialize PCI; 2) provide the ACPI and e820 tables; 3) boot.
>
> If Linux can boot without initializing PCI bridges and without INTX, we
> can remove that code from qboot. The PCI scan is the most expensive
> part, I th
I'm recommend to use packer for this,it able to run via qemu VM,run scripts
and output artifacts.
28 Июн 2016 г. 12:10 пользователь "Niels de Vos"
написал:
> Hi,
>
> it seems we broke the block/gluster.c functionality with a recent patch
> in upstream Gluster. In order to prevent this from happen
Instead of always passing both IO and MEM ranges when
computing CRS ranges, define a new CrsRangeSet structure
that include them both.
This is done before introducing a third type of range,
64-bit MEM, so it will be easier to pass them all around.
Signed-off-by: Marcel Apfelbaum
---
hw/i386/acp
This series fixes 64-bit BARs allocations for devices behind PXBs/PXB-PCIEs.
In build_crs() the calculation and merging of the ranges already happens
in 64-bit, but the entry boundaries are silently truncated to 32-bit in the
call to aml_dword_memory(). Fix it by handling the 64-bit MMIO ranges
s
Add an ivshmem device with 4G shared memory to
pxb in order to check the ACPI code of 64bit MMIO allocation.
Signed-off-by: Marcel Apfelbaum
---
tests/acpi-test-data/pc/DSDT.pxb | Bin 0 -> 6329 bytes
tests/acpi-test-data/q35/DSDT.pxb_pcie | Bin 0 -> 9098 bytes
tests/bios-tables-test.c
In build_crs(), the calculation and merging of the ranges already happens
in 64-bit, but the entry boundaries are silently truncated to 32-bit in the
call to aml_dword_memory(). Fix it by handling the 64-bit MMIO ranges
separately.
This fixes 64-bit BARs behind PXBs.
Signed-off-by: Marcel Apfelba
On 28 June 2016 at 10:24, Stefan Hajnoczi wrote:
> On Mon, Jun 27, 2016 at 02:14:09PM +0200, Thomas Huth wrote:
>> +function show_help {
>> +echo "Usage:"
>> +echo " -s : Start searching by this commit"
>
> s/by/at/
>
>> +echo " -e : End searching by this commit"
>
> s/by/at/
>
>
On 28 June 2016 at 10:01, Peter Lieven wrote:
> coroutine-ucontext currently allocates stack memory from heap as on most
> systems the
> stack size lays below the threshold for mmapping memory. This patch forces
> mmaping
> of stacks to avoid large holes on the heap when a coroutine is deleted.
On 28 June 2016 at 04:35, Jason Wang wrote:
> The following changes since commit 14e60aaece20a1cfc059a69f6491b0899f9257a8:
>
> hw/net/e1000: Don't use *_to_cpup() (2016-06-27 16:39:56 +0100)
>
> are available in the git repository at:
>
> https://github.com/jasowang/qemu.git tags/net-pull-requ
On 06/28/2016 10:53 AM, Cédric Le Goater wrote:
> On 06/28/2016 10:39 AM, Paolo Bonzini wrote:
>> When doing a read-modify-write cycle, QEMU uses the iovec after returning
>> from blk_aio_pwritev. m25p80 puts the iovec on the stack of
>> blk_aio_pwritev's
>> caller, which causes trouble in this c
On 28 June 2016 at 10:01, Peter Lieven wrote:
> Signed-off-by: Peter Lieven
> ---
> include/qom/object.h | 1 +
> qom/object.c | 20 +---
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/include/qom/object.h b/include/qom/object.h
> index 2f8ac47..c61
On Tue, Jun 28, 2016 at 11:39:03AM +0200, Peter Lieven wrote:
> Am 28.06.2016 um 11:29 schrieb Dr. David Alan Gilbert:
> > * Peter Lieven (p...@kamp.de) wrote:
> > > this struct is approx 75kB
> > I wonder why it's so large.
> >
> > The stack size in QmpInputVisitor; it's got a 1024 element stack
On Tue, Jun 28, 2016 at 11:01:35AM +0200, Peter Lieven wrote:
> Signed-off-by: Peter Lieven
> ---
> include/qom/object.h | 1 +
> qom/object.c | 20 +---
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/include/qom/object.h b/include/qom/object.h
> in
* Daniel P. Berrange (berra...@redhat.com) wrote:
> On Tue, Jun 28, 2016 at 11:39:03AM +0200, Peter Lieven wrote:
> > Am 28.06.2016 um 11:29 schrieb Dr. David Alan Gilbert:
> > > * Peter Lieven (p...@kamp.de) wrote:
> > > > this struct is approx 75kB
> > > I wonder why it's so large.
> > >
> > > T
Am 28.06.2016 um 12:10 schrieb Peter Maydell:
On 28 June 2016 at 10:01, Peter Lieven wrote:
Signed-off-by: Peter Lieven
---
include/qom/object.h | 1 +
qom/object.c | 20 +---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/include/qom/object.h b/in
On Tue, Jun 28, 2016 at 11:17:59AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
> > On Tue, Jun 28, 2016 at 11:39:03AM +0200, Peter Lieven wrote:
> > > Am 28.06.2016 um 11:29 schrieb Dr. David Alan Gilbert:
> > > > * Peter Lieven (p...@kamp.de) wrote:
> >
On Thu, Jun 23, 2016 at 01:55:06PM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 20, 2016 at 02:12:17PM +0800, Chao Peng wrote:
> > On Sun, Jun 19, 2016 at 06:51:04AM +0300, Michael S. Tsirkin wrote:
> > > On Fri, Jun 17, 2016 at 04:14:08AM -0400, Chao Peng wrote:
> > > > - it is FAST;
> > >
> >
1 - 100 of 454 matches
Mail list logo
