Il 11/08/2014 13:15, Daniel P. Berrange ha scritto:
>> > 1. Don't throttle. Client can rely on events as long as it keeps the
>> >QMP connection alive. Client should poll after establishing the QMP
>> >connection.
> A malicious guest OS can flood libvirt with events in this way. Of course
Please open a separate bug. Each serial device implementation must
support flow control separately.
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bug
Il 15/08/2014 22:15, Paolo Bonzini ha scritto:
>> > | Random throughput | Sequential throughput
>> > +---+---
>> > master | 442 MB/s | 730 MB/s
>> > base| 453 MB/s | 757 MB/s
>> > bypass (Ming
Il 15/08/2014 23:49, Hulin, Patrick - 0559 - MITLL ha scritto:
>>> In this case, the write is 8 bytes and unaligned, so it gets split
>>> into 8 single-byte writes. In stock QEMU, these writes are done in
>>> reverse order (see the loop in softmmu_template.h, line 402). The
>>> third decryption xor
Hi!
> >>> I think that's more easily done by opening the file as O_RDONLY/O_WRONLY
> >>> /O_RDWR. You could do it by running the file descriptor's seccomp-bpf
> >>> program once per iocb with synthesized syscall numbers and argument
> >>> vectors.
> >>
> >>
> >> Right, but generating the equival
Offsets taken from the L1, L2 and refcount tables are generally assumed
to be correctly aligned. However, this cannot be guaranteed if the image
has been written to by something different than qemu, thus check all
offsets taken from these tables for correct cluster alignment.
Signed-off-by: Max Re
With qcow2_pre_write_overlap_check() relying on
qcow2_signal_corruption(), the output in case of a corruption changes.
Therefore, 060's output has to be adapted accordingly.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/060.out | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Use the new function in case of a failed overlap check.
Signed-off-by: Max Reitz
---
block/qcow2-refcount.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 3b77470..0ac1339 100644
--- a/block/qcow2
Add a helper function for easily marking an image corrupt while
outputting an informative message to stderr and via QAPI.
Signed-off-by: Max Reitz
---
block/qcow2.c | 28
block/qcow2.h | 4
2 files changed, 32 insertions(+)
diff --git a/block/qcow2.c b/block/q
The image fuzzer from Maria exposed a lot of assertions which might fail
in qemu when fed with a broken qcow2 image. Some of them are related to
qemu trusting the offsets given in the L1, L2 and refcount tables to
always be properly aligned on cluster boundaries (e.g.
https://bugs.launchpad.net/qem
On Thu, Aug 14, 2014 at 08:59:17PM -0300, Eduardo Habkost wrote:
> On Thu, Aug 14, 2014 at 11:08:30PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Aug 14, 2014 at 04:25:56PM -0300, Eduardo Habkost wrote:
> > > The "kvmclock" feature is special because it affects two bits in the KVM
> > > CPUID leaf
On Fri Aug 15, 2014 at 14:12:17 +0200, Christoffer Dall wrote:
> On Sun, Aug 03, 2014 at 10:53:46AM +0200, Adam Lackorzynski wrote:
> > Writes to SGIs for GICD_ICFGR register must be ignored.
> >
> > Signed-off-by: Adam Lackorzynski
> > ---
> > hw/intc/arm_gic.c | 11 +++
> > 1 file chan
The following patches address the behavior of the GICD_ICFGR register
in the ARM GIC.
Changes to previous version:
- Setting of model mode only for old GIC revisions
- Less invasive change for PPI settings
Adam
Only SGIs must be WI, done by forcing them to their default
(edge-triggered).
Signed-off-by: Adam Lackorzynski
---
hw/intc/arm_gic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index e546647..55019c9 100644
--- a/hw/intc/arm_gic.c
+++
Setting the model is only available in pre-v1 GIC models.
---
hw/intc/arm_gic.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index d2b1aaf..e546647 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -561,10 +561,12 @@ s
The GICD_ICFGR register covers 4 interrupts per byte.
Acked-by: Christoffer Dall
Signed-off-by: Adam Lackorzynski
---
hw/intc/arm_gic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 1532ef9..d2b1aaf 100644
--- a/hw/intc/arm_gic.c
On 16 August 2014 20:06, Gaurav Sharma wrote:
> Can some one confirm is this is an issue with qemu implementation ?
It's on my todo list to look at. If you want to confirm it as a QEMU
bug your best bet is to write a short test program and compare
the output on QEMU against running it on real har
Can some one confirm is this is an issue with qemu implementation ?
Thanks,
Gaurav
On Thu, Aug 14, 2014 at 1:07 PM, Gaurav Sharma
wrote:
> I am trying to execute a 'fcvt' instruction for conversion from single
> precision to half precision value.
> with the following values :
>
> [Instrn]
> fc
bdrv_is_allocated() may report zero clusters which most probably means
the image (file) is shorter than expected. Respect this case in order to
avoid an infinite loop.
Signed-off-by: Max Reitz
---
qemu-io-cmds.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/qemu-io-cmds
Patch 2:
The bdrv_is_allocated() functions may return a number of zero sectors
e.g. if a sector beyond the image end has been queried. Respect this
case in qemu-io's map implementation so it doesn't run into an infinite
loop (https://bugs.launchpad.net/qemu/+bug/1356969).
Patch 1:
In that bug repo
Add a test for qemu-img map and qemu-io -c map on truncated files.
Signed-off-by: Max Reitz
---
tests/qemu-iotests/102 | 64 ++
tests/qemu-iotests/102.out | 11
tests/qemu-iotests/group | 1 +
3 files changed, 76 insertions(+)
create m
When falling through to the underlying file in
bdrv_co_get_block_status(), do not let the number of sectors for which
information could be obtained be overwritten.
Signed-off-by: Max Reitz
---
block.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
ind
On 16 August 2014 03:24, Zhang Haoyu wrote:
> I download one copy of qemu-2.0.0 from http://wiki.qemu.org/Download,
> and then download another copy of qemu-2.0.0 from http://git.qemu.org/qemu.git
The latter of these is our git repository. pixman, dtc and roms are kept
in git submodules, and git
Hi,
being on 2d591ce2aeebf, I rather receive "qemu-img: Error while amending
options: File too large". Judging from the traces, though, this issue
(the segfault at least) should be fixed by my "[PATCH v3 0/7]
block/qcow2: Improve zero cluster expansion" series anyway (when merged
eventually).
Max
Hi,
This issue should be fixed by my "[PATCH v3 0/7] block/qcow2: Improve
zero cluster expansion" series.
However, there are similar issues in qemu, so we'll probably need a
function to quickly mark an image corrupt instead of throwing these
assertions.
Max
--
You received this bug notificatio
Although the bug has been fixed in qemu-system-i386 and qemu-system-
x86_64, it is still present in qemu-system-sparc. I'm attaching an
updated version of the "Method 1" shell script which reproduces the
problem with qemu 2.1.0.
When I run it, the last output is:
<0919>
<0920>
<092964
On Sat, 2014-08-16 at 14:48 +0800, Zhang Haoyu wrote:
> >> Hi, all
> >> I'm using VFIO to assign intel 82599 VF to VM, now I encounter a problem,
> >> 82599 PF and its VFs belong to the same iommu_group, but I only want to
> >> assign some VFs to one VM, and some other VFs to another VM, ...,
> >>
On 16 August 2014 10:50, Piotr Król wrote:
> On Fri, Aug 15, 2014 at 11:54:55PM +0100, Peter Maydell wrote:
>> I'm not looking for advocacy, just for an explanation of what it's
>> doing, and in particular whether anybody's ever tested this on real
>> hardware. (Running guest code only on QEMU is
On 16 August 2014 02:08, Eric Blake wrote:
> In file included from /usr/include/spice-server/spice.h:25:0,
> from /home/eblake/qemu-tmp/include/ui/qemu-spice.h:25,
> from qemu-char.c:84:
> /usr/include/spice-1/spice/macros.h:105:0: error: "INLINE" redefined
> [-We
On Fri, Aug 15, 2014 at 11:54:55PM +0100, Peter Maydell wrote:
> I'm not looking for advocacy, just for an explanation of what it's
> doing, and in particular whether anybody's ever tested this on real
> hardware. (Running guest code only on QEMU is a recipe for bugs,
> because our emulation is oft
On 2014-08-16 10:45, Jan Kiszka wrote:
> On 2014-08-16 09:54, Knut Omang wrote:
>> On Fri, 2014-08-15 at 19:37 +0800, Le Tan wrote:
>>> Hi Knut,
>>>
>>> 2014-08-15 19:15 GMT+08:00 Knut Omang :
On Fri, 2014-08-15 at 06:42 +0200, Knut Omang wrote:
> On Thu, 2014-08-14 at 14:10 +0200, Jan Kis
On 2014-08-16 09:54, Knut Omang wrote:
> On Fri, 2014-08-15 at 19:37 +0800, Le Tan wrote:
>> Hi Knut,
>>
>> 2014-08-15 19:15 GMT+08:00 Knut Omang :
>>> On Fri, 2014-08-15 at 06:42 +0200, Knut Omang wrote:
On Thu, 2014-08-14 at 14:10 +0200, Jan Kiszka wrote:
> On 2014-08-14 13:15, Michael S
On 8/16/14, Paolo Bonzini wrote:
> Il 14/08/2014 12:46, Kevin Wolf ha scritto:
>> So to finally reply with some numbers... I'm running fio tests based on
>> Ming's configuration on a loop-mounted tmpfs image using dataplane.
>
> I'm not sure tmpfs is a particularly useful comparison, since it does
On Fri, 2014-08-15 at 19:37 +0800, Le Tan wrote:
> Hi Knut,
>
> 2014-08-15 19:15 GMT+08:00 Knut Omang :
> > On Fri, 2014-08-15 at 06:42 +0200, Knut Omang wrote:
> >> On Thu, 2014-08-14 at 14:10 +0200, Jan Kiszka wrote:
> >> > On 2014-08-14 13:15, Michael S. Tsirkin wrote:
> >> > > On Mon, Aug 11,
34 matches
Mail list logo
