any change with the attached patch?
** Patch added: "0001-pulseaudio-process-audio-data-in-smaller-chunks.patch"
https://bugs.launchpad.net/qemu/+bug/1795527/+attachment/5210653/+files/0001-pulseaudio-process-audio-data-in-smaller-chunks.patch
--
You received this bug notification because
Hi,
It’s observed that GTK display performs poorly compared with native
environment. The display refresh timer fires at a interval of
GUI_REFRESH_INTERVAL_DEFAULT milliseconds which is defined as 30 in
include/ui/console.h. This throttles refresh rate to 33Hz.
Changing its value to 16 (i.e.
On 11/8/18 8:12 PM, Palmer Dabbelt wrote:
> * We don't take advantage of the ordering bits on fences, which could allow us
> to emit less conservative fences. This would presumably increase
> performance.
Yes.
> * We treat fences as NOPs under "#ifndef CONFIG_USER_ONLY", which is a bug.
Ah
On 11/08/2018 07:04 PM, Peter Maydell wrote:
On 8 November 2018 at 10:59, Li Zhijian wrote:
allow load_image to load >= 2G file
CC: Philip Li
Signed-off-by: Li Zhijian
---
hw/core/loader.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/core/loader.c
On 2018/11/9 上午12:48, Liang, Cunming wrote:
-Original Message-
From: Jason Wang [mailto:jasow...@redhat.com]
Sent: Thursday, November 8, 2018 2:16 AM
To: Liang, Cunming; Wang, Xiao W
;m...@redhat.com;alex.william...@redhat.com
Cc:qemu-devel@nongnu.org; Bie, Tiwei; Ye, Xiaolong
; Wang,
On 11/08/2018 07:06 PM, Peter Maydell wrote:
On 8 November 2018 at 10:59, Li Zhijian wrote:
x86/x86_64 has alredy supported 4G initrd.
linux/arch/x86/boot/header.S:
# (Header version 0x0203 or later) the highest safe address for the contents
# of an initrd. The current kernel allows up
On 11/09/2018 12:47 AM, Michael S. Tsirkin wrote:
> On Thu, Nov 08, 2018 at 10:09:00PM +0800, Dongli Zhang wrote:
>> It looks the kernel space vhost-blk can only process raw image.
>>
>> How about to verify that only raw image is used in the drive command line
>> when
>> vhost-blk-pci is
On 11/8/18 1:26 PM, Eduardo Habkost wrote:
> On Thu, Nov 08, 2018 at 12:36:37PM -0500, Cleber Rosa wrote:
>>
>>
>> On 11/8/18 11:51 AM, Eduardo Habkost wrote:
>>
>>> I'm not sure I agree with the "is an important thing to keep
>>> track of" part. I don't think we'll have any need to keep track
Hi,
This series failed docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20181102170730.12432-1-cont...@steffen-goertz.de
Subject: [Qemu-devel] [PATCH v4 00/13]
On Thu, Nov 08, 2018 at 08:19:42AM -0600, miny...@acm.org wrote:
> The code was using the qemu UUID for the BMC. But that's really
> not a good method. In general, you don't want the GUID to change
> when you migrate, and you want the GUID to be the same between
> invocations of qemu (if you
Hi,
This series failed docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 1541672153-15529-1-git-send-email-gengdong...@huawei.com
Subject: [Qemu-devel] [PATCH
Hi,
This series failed docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 1541672989-15967-1-git-send-email-gengdong...@huawei.com
Subject: [Qemu-devel] [PATCH
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1541672989-15967-1-git-send-email-gengdong...@huawei.com
Subject: [Qemu-devel] [PATCH RESEND v15 00/10] Add ARMv8 RAS virtualization
support in QEMU
=== TEST SCRIPT BEGIN
Hi,
This series failed docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
Type: series
Message-id: 20181102170730.12432-1-cont...@steffen-goertz.de
Subject: [Qemu-devel] [PATCH v4 00/13]
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1541672153-15529-1-git-send-email-gengdong...@huawei.com
Subject: [Qemu-devel] [PATCH v15 00/10] Add ARMv8 RAS virtualization support in
QEMU
=== TEST SCRIPT BEGIN ===
On Thu, 8 Nov 2018, Fredrik Noring wrote:
> > Fredrik, do you know by any chance if a document exists that would justify
> > inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by
> > gcc for R5900? Is it included by cross-gcc or by native gcc, or by both?
> >
> > I think gcc
On Thu, Nov 08, 2018 at 09:28:06PM +0100, Paolo Bonzini wrote:
> Oops. :)
>
> On 08/11/2018 19:42, Eduardo Habkost wrote:
> >>> Keeping in mind that I might be talking about extra challenges we
> >>> won't address right now (no cart before the horse), I have new
> >>> questions:
> >>>
> >>> Why
On 08/11/2018 19:41, Liran Alon wrote:
> So what I plan to do is indeed to define first 4K of data as vmcs12 and next
> 4K as shadow_vmcs12.
> I will also define each of them in a separate VMState subsection that each
> will have it’s own .needed()
> method that will decide if it’s relevant to
The assumption that the fid cannot be used by any other operation is
wrong. At least, nothing prevents a misbehaving client to create a
file with a given fid, and to pass this fid to some other operation
at the same time (ie, without waiting for the response to the creation
request). The call to
The following changes since commit a7ce790a029bd94eb320d8c69f38900f5233997e:
tcg/tcg-op.h: Add multiple include guard (2018-11-08 15:15:32 +)
are available in the Git repository at:
https://github.com/gkurz/qemu.git tags/for-upstream
for you to fetch changes up to
On Thu, Nov 08, 2018 at 05:26:06PM +0100, Cornelia Huck wrote:
> On Thu, 8 Nov 2018 18:08:15 +0200
> Yuval Shaia wrote:
>
> > Notifier will be used for signaling shutdown event to inform system is
> > shutdown. This will allow devices and other component to run some
> > cleanup code needed
Oops. :)
On 08/11/2018 19:42, Eduardo Habkost wrote:
>>> Keeping in mind that I might be talking about extra challenges we
>>> won't address right now (no cart before the horse), I have new
>>> questions:
>>>
>>> Why you say backends are not a target configuration and
>>> accelerators are?
Under review, the following patch adds acceptance tests for the initrd
option:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg567776.html
The test should be updated in case this series get merged. Maybe the
best would be to include those tests along with this series actually.
-
On Thu, 08 Nov 2018 09:29:26 PST (-0800), Bastian Koppelmann wrote:
On 11/8/18 4:53 PM, Richard Henderson wrote:
On 11/8/18 1:06 PM, Bastian Koppelmann wrote:
while going through the reviews of the riscv-decodetree patches, two bugs came
up that I fix here. There is one more problem [1]
On Wed, Nov 7, 2018 at 1:52 PM Alistair Francis
wrote:
> Signed-off-by: Alistair Francis
> ---
> hw/riscv/virt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 4a137a503c..2b38f89070 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
>
On Thu, 08 Nov 2018 10:38:51 PST (-0800), alistai...@gmail.com wrote:
On Thu, Nov 8, 2018 at 10:35 AM Palmer Dabbelt wrote:
The following changes since commit a7ce790a029bd94eb320d8c69f38900f5233997e:
tcg/tcg-op.h: Add multiple include guard (2018-11-08 15:15:32 +)
are available in
Hi Aleksandar,
> Fredrik, do you know by any chance if a document exists that would justify
> inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by
> gcc for R5900? Is it included by cross-gcc or by native gcc, or by both?
>
> I think gcc folks must have had a good reason for
On Thu, 08 Nov 2018 10:37:28 PST (-0800), alistai...@gmail.com wrote:
On Wed, Nov 7, 2018 at 6:38 PM Palmer Dabbelt wrote:
On Wed, 07 Nov 2018 13:51:45 PST (-0800), Alistair Francis wrote:
> Signed-off-by: Alistair Francis
> ---
> hw/riscv/virt.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
On Thu, Nov 8, 2018 at 7:43 PM Markus Armbruster wrote:
> Peter Maydell writes:
> > On 8 November 2018 at 18:08, Philippe Mathieu-Daudé
> > wrote:
> >> Anyway there are no information about merge window in the wiki.
> >> When I started it was not easy to understand it and why patches sent when
The R5900 reports itself as MIPS III but does not implement DMULT.
Verify that DMULT is emulated properly in user mode by multiplying
two 64-bit numbers to produce a 128-bit number.
Signed-off-by: Fredrik Noring
---
tests/tcg/mips/mipsn32r5900/Makefile | 25 +
Peter Maydell writes:
> On 8 November 2018 at 18:08, Philippe Mathieu-Daudé wrote:
>> Anyway there are no information about merge window in the wiki.
>> When I started it was not easy to understand it and why patches sent when
>> 'merge window is close' fall under the crap and are unnoticed,
Recognise the R5900, which reports itself as MIPS III, as a 64-bit CPU
supporting the n32 ABI.
Signed-off-by: Fredrik Noring
---
linux-user/mips64/target_elf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/linux-user/mips64/target_elf.h b/linux-user/mips64/target_elf.h
index
On Thu, Nov 08, 2018 at 06:58:11PM +0100, Paolo Bonzini wrote:
> On 08/11/2018 18:14, Eduardo Habkost wrote:
> > Keeping in mind that I might be talking about extra challenges we
> > won't address right now (no cart before the horse), I have new
> > questions:
> >
> > Why you say backends are not
Recognise the R5900, which reports itself as MIPS III, as a 64-bit CPU
supporting the n32 ABI. Test that DMULT is emulated in user mode.
This series has been successfully built with the 10 different build
configurations
{gcc,clang} x -m64 x mips{,64}el-{linux-user,softmmu}
{gcc,clang} x
> On 8 Nov 2018, at 19:02, Paolo Bonzini wrote:
>
> On 08/11/2018 10:57, Liran Alon wrote:
>>
>>
>>> On 8 Nov 2018, at 11:50, Paolo Bonzini wrote:
>>>
>>> On 08/11/2018 01:45, Jim Mattson wrote:
I have no attachments to the current design. I had used a data[] blob,
because I
On Thu, Nov 8, 2018 at 10:35 AM Palmer Dabbelt wrote:
>
> The following changes since commit a7ce790a029bd94eb320d8c69f38900f5233997e:
>
> tcg/tcg-op.h: Add multiple include guard (2018-11-08 15:15:32 +)
>
> are available in the Git repository at:
>
> git://github.com/riscv/riscv-qemu.git
On Wed, Nov 7, 2018 at 6:38 PM Palmer Dabbelt wrote:
>
> On Wed, 07 Nov 2018 13:51:45 PST (-0800), Alistair Francis wrote:
> > Signed-off-by: Alistair Francis
> > ---
> > hw/riscv/virt.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > index
The following changes since commit a7ce790a029bd94eb320d8c69f38900f5233997e:
tcg/tcg-op.h: Add multiple include guard (2018-11-08 15:15:32 +)
are available in the Git repository at:
git://github.com/riscv/riscv-qemu.git tags/riscv-for-master-3.1-rc1
for you to fetch changes up to
From: Alistair Francis
Coverity caught a malloc() call that was never freed. This patch ensures
that we free the memory but also updates the allocation to use
g_strdup_printf() instead of malloc().
Signed-off-by: Alistair Francis
Suggested-by: Peter Maydell
Reviewed-by: Peter Maydell
On Thu, Nov 08, 2018 at 12:36:37PM -0500, Cleber Rosa wrote:
>
>
> On 11/8/18 11:51 AM, Eduardo Habkost wrote:
>
> > I'm not sure I agree with the "is an important thing to keep
> > track of" part. I don't think we'll have any need to keep track
> > of the Python version in shell script or
Hello,
I recently had to extend QEMU user mode to support PIE enabled binaries
compiled for non-native architectures. It was also important to emulate ASLR
for the target binary if ASLR was enabled on the host machine. I would like to
introduce this as a feature into QEMU mainstream as it
Ran through the commits included in the audio code merge, with the
following results:
[commit 280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d]
audio/hda: create millisecond timers that handle IO
Audio stream gets progressively more and more corrupted, breaking completely
between 30'' and 1' after
On 8 November 2018 at 18:08, Philippe Mathieu-Daudé wrote:
> Anyway there are no information about merge window in the wiki.
> When I started it was not easy to understand it and why patches sent when
> 'merge window is close' fall under the crap and are unnoticed, thus it is
> better to wait
On 07/11/2018 23:04, George Kennedy wrote:
> Your latest suggestion was the "missing link". Calling lsi_wait_reselect()
> after a WAIT DISCONNECT Script instruction when there are commands on
> the pending queue is all the is needed. The patch has been greatly
> reduced in size and complexity.
On 8/11/18 19:00, Peter Maydell wrote:
On 8 November 2018 at 17:41, Philippe Mathieu-Daudé wrote:
On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell wrote:
On 8 November 2018 at 17:17, Eduardo Habkost wrote:
On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
Reported-by:
On 8 November 2018 at 17:41, Philippe Mathieu-Daudé wrote:
> On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell wrote:
>> On 8 November 2018 at 17:17, Eduardo Habkost wrote:
>> > On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
>> >> Reported-by: LGTM code review
>> >>
On 08/11/2018 18:14, Eduardo Habkost wrote:
> Keeping in mind that I might be talking about extra challenges we
> won't address right now (no cart before the horse), I have new
> questions:
>
> Why you say backends are not a target configuration and
> accelerators are? What's the definition of
On 8 November 2018 at 17:58, Corey Minyard wrote:
> On 11/8/18 8:08 AM, Peter Maydell wrote:
>> This doesn't do anything for migration of the actual data contents.
>> The current users of this device (hw/arm/aspeed.c and the
>> smbus_eeprom_init() function) doesn't do anything
>> to migrate the
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/cpu.h | 6 +-
linux-user/elfload.c | 2 +-
target/arm/cpu.c | 4
target/arm/helper.c | 2 +-
target/arm/kvm32.c | 3 ---
target/arm/machine.c | 3 +--
6 files changed, 8 insertions(+), 12 deletions(-)
Signed-off-by: Richard Henderson
---
target/arm/kvm64.c | 90 --
1 file changed, 88 insertions(+), 2 deletions(-)
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index 5de8ff0ac5..e1128b94b2 100644
--- a/target/arm/kvm64.c
+++
On 11/8/18 8:08 AM, Peter Maydell wrote:
On 7 November 2018 at 15:54, wrote:
From: Corey Minyard
This was if the eeprom is accessed during a state transfer, the
transfer will be reliable.
Signed-off-by: Corey Minyard
Cc: Paolo Bonzini
Cc: Michael S. Tsirkin
Cc: Dr. David Alan Gilbert
Assert that the value to be written is the correct size.
No change in functionality here, just mirroring the same
function from kvm64.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/kvm32.c | 41 -
1 file changed, 16
The ID registers are replacing (some of) the feature bits.
We need (some of) these values to determine the set of data
to be handled during migration.
Reviewed-by: Peter Maydell
Signed-off-by: Richard Henderson
---
target/arm/kvm_arm.h | 1 +
target/arm/kvm.c | 1 +
2 files changed, 2
My previous patch set for replacing feature bits with id registers
failed to consider that these id registers are beginning to control
migration, and thus we must fill them in for KVM as well.
Thus, we want to initialize these values within CPU from the host.
Finally, re-send the T32EE
Signed-off-by: Richard Henderson
---
target/arm/kvm32.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/target/arm/kvm32.c b/target/arm/kvm32.c
index de573f9aa8..9ededa3c73 100644
--- a/target/arm/kvm32.c
+++ b/target/arm/kvm32.c
@@ -44,7
On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell wrote:
> On 8 November 2018 at 17:17, Eduardo Habkost wrote:
> > On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
> >> Reported-by: LGTM code review
> >> Signed-off-by: Philippe Mathieu-Daudé
> >
> > Queueing for 3.2, thanks.
>
On 11/8/18 11:51 AM, Eduardo Habkost wrote:
> I'm not sure I agree with the "is an important thing to keep
> track of" part. I don't think we'll have any need to keep track
> of the Python version in shell script or makefiles after we start
> requiring Python 3.
>
Well, "Python 3" is not a
Richard Henderson writes:
> On 11/8/18 5:33 PM, Alex Bennée wrote:
>> -.bvr = addr
>> +.bvr = sextract64(addr, 52, 53)
>
> I think you meant sextract64(addr, 0, 53).
> What you wrote *should* have asserted, since 52+53 > 64.
Dam, I did fix that. I must have failed to propagate
On 11/8/18 4:53 PM, Richard Henderson wrote:
On 11/8/18 1:06 PM, Bastian Koppelmann wrote:
while going through the reviews of the riscv-decodetree patches, two bugs came
up that I fix here. There is one more problem [1] mentioned by Richard but
I don't have the time to investigate it further.
On 8 November 2018 at 17:17, Eduardo Habkost wrote:
> On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
>> Reported-by: LGTM code review
>> Signed-off-by: Philippe Mathieu-Daudé
>
> Queueing for 3.2, thanks.
Next release after 3.1 will be 4.0, by the way -- we're moving
to
On 11/8/18 5:33 PM, Alex Bennée wrote:
> The test was incomplete and incorrectly caused debug exceptions to be
> generated when returning to EL2 after a failed attempt to single-step
> an EL1 instruction. Fix this while cleaning up the function a little.
>
> Signed-off-by: Alex Bennée
> ---
>
On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
> Reported-by: LGTM code review
> Signed-off-by: Philippe Mathieu-Daudé
Queueing for 3.2, thanks.
--
Eduardo
On Thu, Nov 08, 2018 at 02:42:19PM +0100, Paolo Bonzini wrote:
> On 08/11/2018 14:06, Eduardo Habkost wrote:
> > On Thu, Nov 08, 2018 at 10:55:21AM +0100, Paolo Bonzini wrote:
> >> On 07/11/2018 20:30, Thomas Huth wrote:
> >>> On 2018-11-07 20:24, Eduardo Habkost wrote:
> On Wed, Nov 07, 2018
On 11/8/18 5:33 PM, Alex Bennée wrote:
> We already have this symbol defined so lets use it.
>
> Signed-off-by: Alex Bennée
> ---
> target/arm/cpu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard Henderson
r~
On 11/8/18 5:33 PM, Alex Bennée wrote:
> @@ -16,6 +16,7 @@ def report(cond, msg):
> print ("PASS: %s" % (msg))
> else:
> print ("FAIL: %s" % (msg))
> +global failcount
> failcount += 1
Do we usually prefer such declarations at the start of the function?
On 11/8/18 5:33 PM, Alex Bennée wrote:
> When we are debugging the guest all exceptions come our way but might
> be for the guest's own debug exceptions. We use the ->do_interrupt()
> infrastructure to inject the exception into the guest. However, we are
> missing a full setup of the exception
On 11/8/18 5:33 PM, Alex Bennée wrote:
> Fix the assertion failure when running interrupts.
>
> Signed-off-by: Alex Bennée
> Reviewed-by: Peter Maydell
> ---
> target/arm/kvm64.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Richard Henderson
r~
On 11/8/18 5:33 PM, Alex Bennée wrote:
> -.bvr = addr
> +.bvr = sextract64(addr, 52, 53)
I think you meant sextract64(addr, 0, 53).
What you wrote *should* have asserted, since 52+53 > 64.
r~
Jeb, if you open a bug against QEMU here, we expect some information how
QEMU is run. If you only interact with Gnome Boxes, then please only
open a bug against Boxes - best in their Bug tracker here:
https://bugzilla.gnome.org/ ... I guess nobody of the Boxes project is
checking Launchpad, so
And for the CLI parameters, you could run this in a console window for
example, after starting your guest:
ps aux | grep qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1734810
Title:
Windows
At least please try to answer my questions in comment #3: Is
virtualization enabled in your BIOS? Is KVM enabled on your system (i.e.
are the kvm.ko and kvm_intel.ko or kvm_amd.ko modules loaded)?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
On 08/11/2018 10:57, Liran Alon wrote:
>
>
>> On 8 Nov 2018, at 11:50, Paolo Bonzini wrote:
>>
>> On 08/11/2018 01:45, Jim Mattson wrote:
>>> I have no attachments to the current design. I had used a data[] blob,
>>> because I didn't think userspace would have any need to know what was
>>> in
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 08 November 2018 15:44
> To: 'Kevin Wolf'
> Cc: Stefano Stabellini ; qemu-bl...@nongnu.org;
> Tim Smith ; qemu-devel@nongnu.org; 'Markus
> Armbruster' ; Anthony
Oh and yeah, I just kind of realized that the original issue simply appears
after the new timers are being activated by default.
Well, that should have been pretty obvious.
I'll try to actuvate them at compile time and see where this path leads to.
And sorry for misclicking on the information
On Thu, Nov 08, 2018 at 05:23:14PM +0100, Philippe Mathieu-Daudé wrote:
> On Thu, Nov 8, 2018 at 5:17 PM Philippe Mathieu-Daudé
> wrote:
> > On 6/11/18 12:05, Luc Michel wrote:
> > > This commit adds the cpu-cluster type. It aims at gathering CPUs from
> > > the same cluster in a machine.
> > >
On Thu, Nov 08, 2018 at 11:06:45AM -0500, Cleber Rosa wrote:
>
>
> On 11/8/18 3:45 AM, Markus Armbruster wrote:
> > Cleber Rosa writes:
> >
> >> On 11/7/18 1:05 AM, Markus Armbruster wrote:
> >>> Eduardo Habkost writes:
> >>>
> The $(SHELLSTATUS) variable requires GNU make >= 4.2, but
Hello Laurent,
On 11/8/18 10:10 AM, Laurent Vivier wrote:
> On 26/10/2018 14:33, P J P wrote:
>> From: Prasad J Pandit
>>
>> While performing PowerNV memory r/w operations, the access length
>> 'sz' could exceed the data[4] buffer size. Add check to avoid OOB
>> access.
>>
>> Reported-by:
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Thursday, November 8, 2018 2:16 AM
> To: Liang, Cunming ; Wang, Xiao W
> ; m...@redhat.com; alex.william...@redhat.com
> Cc: qemu-devel@nongnu.org; Bie, Tiwei ; Ye, Xiaolong
> ; Wang, Zhihong ; Daly, Dan
>
>
On Thu, Nov 08, 2018 at 10:09:00PM +0800, Dongli Zhang wrote:
> It looks the kernel space vhost-blk can only process raw image.
>
> How about to verify that only raw image is used in the drive command line when
> vhost-blk-pci is paired with it?
>
> Otherwise, vhost-blk-pci might be working with
** Attachment added: "[ORIGINAL ISSUE LOG]"
https://bugs.launchpad.net/qemu/+bug/1795527/+attachment/5210397/+files/qemu_bisect_original_issue.txt
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
GIT BISECT RESULTS
So, I managed to run the git bisection and ended up having to do it
twice: once looking for the first commit that broke audio (turns out a
major total breakage occurs before the original diagnosed issue
appeared), then to spot the origin of the main issue (I ignored the
other
On Thu, 2018-11-08 at 11:05 +0100, Lukáš Hrázký wrote:
> Hello,
>
> On Thu, 2018-11-08 at 07:49 +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > + * The device_display_id_{start,count} denotes the sequence of
> > > device display
> > > + * IDs that map to the zero-based sequence of monitor IDs
>
We already have this symbol defined so lets use it.
Signed-off-by: Alex Bennée
---
target/arm/cpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index b5eff79f73..1efff21a18 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@
The test was incomplete and incorrectly caused debug exceptions to be
generated when returning to EL2 after a failed attempt to single-step
an EL1 instruction. Fix this while cleaning up the function a little.
Signed-off-by: Alex Bennée
---
target/arm/cpu.h | 27 +--
1
This only fails with some (broken) versions of gdb but we should
treat the top bits of DBGBVR as RESS. Properly sign extend QEMU's
reference copy of dbgbvr and also update the register descriptions in
the comment.
Signed-off-by: Alex Bennée
---
v2
- sanitise register on insertion
- update
Fix the assertion failure when running interrupts.
Signed-off-by: Alex Bennée
Reviewed-by: Peter Maydell
---
target/arm/kvm64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c
index b92ce3437f..03b0f78831 100644
--- a/target/arm/kvm64.c
+++
Hi,
These are fixes for guest debug when running under KVM. While
re-spinning these I came across an anomaly which pointed to a kernel
bug that caused the 1st single-step to fail. This is being discussed
on the kvm-arm list:
Subject: [RFC PATCH] KVM: arm64: don't single-step for non-emulated
You should declare you are using a global version of a variable before
you attempt to modify it in a function.
Signed-off-by: Alex Bennée
Reviewed-by: Peter Maydell
---
tests/guest-debug/test-gdbstub.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/guest-debug/test-gdbstub.py
When we are debugging the guest all exceptions come our way but might
be for the guest's own debug exceptions. We use the ->do_interrupt()
infrastructure to inject the exception into the guest. However, we are
missing a full setup of the exception structure, causing an assert
later down the line.
On 6/11/18 12:05, Luc Michel wrote:
This commit adds the cpu-cluster type. It aims at gathering CPUs from
the same cluster in a machine.
For now it only has a `cluster-id` property.
Signed-off-by: Luc Michel
Reviewed-by: Alistair Francis
---
include/hw/cpu/cluster.h | 38
On Thu, 8 Nov 2018 18:08:15 +0200
Yuval Shaia wrote:
> Notifier will be used for signaling shutdown event to inform system is
> shutdown. This will allow devices and other component to run some
> cleanup code needed before VM is shutdown.
>
> Signed-off-by: Yuval Shaia
> ---
>
Signed-off-by: Yuval Shaia
---
hw/rdma/rdma_rm.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c
index 35a96d9a64..e3f6b2f6ea 100644
--- a/hw/rdma/rdma_rm.c
+++ b/hw/rdma/rdma_rm.c
@@ -555,6 +555,10 @@ int rdma_rm_del_gid(RdmaDeviceResources
On Thu, Nov 8, 2018 at 5:17 PM Philippe Mathieu-Daudé wrote:
> On 6/11/18 12:05, Luc Michel wrote:
> > This commit adds the cpu-cluster type. It aims at gathering CPUs from
> > the same cluster in a machine.
> >
> > For now it only has a `cluster-id` property.
> >
> > Signed-off-by: Luc Michel
>
On 6/11/18 12:05, Luc Michel wrote:
changes since v3:
- patch 1cpu_cluster.h: remove QEMU_ from the multiple includes
guard #ifdef/#define [Alistair]
- patch 1cpu_cluster.c: include osdep.h first [Alistair]
- patch 1use uint64_t for cluster ID for
opcode for WC should be set by the device and not taken from work
element.
Signed-off-by: Yuval Shaia
---
hw/rdma/vmw/pvrdma_qp_ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rdma/vmw/pvrdma_qp_ops.c b/hw/rdma/vmw/pvrdma_qp_ops.c
index 7b0f440fda..3388be1926 100644
Device supports only one port, let's remove a dead code that handles
more than one port.
Signed-off-by: Yuval Shaia
---
hw/rdma/rdma_rm.c | 34 --
hw/rdma/rdma_rm.h | 2 +-
hw/rdma/rdma_rm_defs.h | 4 ++--
3 files changed, 19 insertions(+), 21
Signed-off-by: Yuval Shaia
---
hw/rdma/rdma_rm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/rdma/rdma_rm.c b/hw/rdma/rdma_rm.c
index 0a5ab8935a..35a96d9a64 100644
--- a/hw/rdma/rdma_rm.c
+++ b/hw/rdma/rdma_rm.c
@@ -43,7 +43,7 @@ static inline void
pvrdma requires that the same GID attached to it will be attached to the
backend device in the host.
A new QMP messages is defined so pvrdma device can broadcast any change
made to its GID table. This event is captured by libvirt which in turn
will update the GID table in the backend device.
pvrdma setup requires vmxnet3 device on PCI function 0 and PVRDMA device
on PCI function 1.
pvrdma device needs to access vmxnet3 device object for several reasons:
1. Make sure PCI function 0 is vmxnet3.
2. To monitor vmxnet3 device state.
3. To configure node_guid accoring to vmxnet3 device's
node_guid should be set once device is load.
Make node_guid be GID format (32 bit) of PCI function 0 vmxnet3 device's
MAC.
A new function was added to do the conversion.
So for example the MAC 56:b6:44:e9:62:dc will be converted to GID
54b6:44ff:fee9:62dc.
Signed-off-by: Yuval Shaia
---
1 - 100 of 309 matches
Mail list logo
