* Eric Blake (ebl...@redhat.com) wrote:
> On 9/11/19 11:42 AM, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
> > g_auto infrastrcture (and thus whatever the compilers hooks are) to
> > release it on
* Eric Blake (ebl...@redhat.com) wrote:
> On 9/11/19 11:56 AM, Daniel P. Berrangé wrote:
> > On Wed, Sep 11, 2019 at 05:42:00PM +0100, Dr. David Alan Gilbert (git)
> > wrote:
> >> From: "Dr. David Alan Gilbert"
> >>
> >> RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
>
> spurio
* Eric Blake (ebl...@redhat.com) wrote:
> On 9/11/19 12:40 PM, Eric Blake wrote:
>
> >> +
> >> +#define RCU_READ_LOCK_AUTO g_auto(rcu_read_auto_t) \
> >> +_rcu_read_auto = 'x'; \
> >
> > I'm a bit lost at where _rcu_read_auto is declared. (I could understand
> > if an earlier macro had creat
On 9/11/19 12:29 PM, Thomas Huth wrote:
> When running "make distclean" we currently leave a lot of generated
> files in the build directory. Fix that.
>
> Signed-off-by: Thomas Huth
Nice,
Reviewed-by: John Snow
> ---
> Makefile | 6 +++---
> tests/Makefile.include | 12 +++
On 9/11/19 11:13 AM, Vladimir Sementsov-Ogievskiy wrote:
> 07.08.2019 19:27, John Snow wrote:
>>
>>
>> On 8/6/19 12:19 PM, Vladimir Sementsov-Ogievskiy wrote:
>>> 06.08.2019 19:09, Max Reitz wrote:
On 06.08.19 17:26, Vladimir Sementsov-Ogievskiy wrote:
> hbitmap_reset has an unobvious p
On 9/11/19 11:56 AM, Daniel P. Berrangé wrote:
> On Wed, Sep 11, 2019 at 05:42:00PM +0100, Dr. David Alan Gilbert (git) wrote:
>> From: "Dr. David Alan Gilbert"
>>
>> RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
spurious double space
>> g_auto infrastrcture (and thus whatever
On 9/11/19 12:40 PM, Eric Blake wrote:
>> +
>> +#define RCU_READ_LOCK_AUTO g_auto(rcu_read_auto_t) \
>> +_rcu_read_auto = 'x'; \
>
> I'm a bit lost at where _rcu_read_auto is declared. (I could understand
> if an earlier macro had created that typedef via concatenating _ with
> rcu_read_auto
On 9/11/19 11:42 AM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
> g_auto infrastrcture (and thus whatever the compilers hooks are) to
> release it on all exits of the block.
>
> Note this macro has a v
On 09/10/19 17:58, Igor Mammedov wrote:
> On Mon, 9 Sep 2019 21:15:44 +0200
> Laszlo Ersek wrote:
[...]
> It looks like fwcfg smi feature negotiation isn't reusable in this case.
> I'd prefer not to add another device just for another SMI feature
> negotiation/activation.
I thought it could be
Hi to all
I try to use ( into VM debian 10 running into VMWARE virtualization
environment ) qemu ppc64 version to simulate an AIX 7.1 TL04 OS
root@vkvm-acmm:/AIX# qemu-system-ppc64 -version
QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u2)
Copyright (c) 2003-2018 Fabrice Bellard and
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Sep 11, 2019 at 05:42:01PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > Use the automatic read unlocker in migration/ram.c;
> > only for the cases where the unlock is at the end of the function.
>
On 9/11/19 11:15 AM, Sergio Lopez wrote:
> On creation, the export's AioContext is set to the same one as the
> BlockBackend, while the AioContext in the client QIOChannel is left
> untouched.
>
> As a result, when using data-plane, nbd_client_receive_next_request()
> schedules coroutines in the I
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Sep 11, 2019 at 06:10:28PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Wed, Sep 11, 2019 at 06:04:23PM +0100, Dr. David Alan Gilbert wrote:
> > > > * Daniel P. Berrangé (berra...@redh
On Wed, Sep 11, 2019 at 06:10:28PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > On Wed, Sep 11, 2019 at 06:04:23PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > > On Wed, Sep 11, 2019 at 05:42:00PM
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Sep 11, 2019 at 05:41:59PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > This patch uses glib's g_auto mechanism to automatically free
> > rcu_read_lock's at the end of the block. Given that human
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Sep 11, 2019 at 06:04:23PM +0100, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > On Wed, Sep 11, 2019 at 05:42:00PM +0100, Dr. David Alan Gilbert (git)
> > > wrote:
> > > > From: "Dr. David Alan
On Wed, Sep 11, 2019 at 06:04:23PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > On Wed, Sep 11, 2019 at 05:42:00PM +0100, Dr. David Alan Gilbert (git)
> > wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > RCU_READ_LOCK_AUTO takes the rcu_read
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Wed, Sep 11, 2019 at 05:42:00PM +0100, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
> > g_auto infrastrcture (and thus whatever the compilers h
On Wed, Sep 11, 2019 at 05:42:01PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> Use the automatic read unlocker in migration/ram.c;
> only for the cases where the unlock is at the end of the function.
>
> Signed-off-by: Dr. David Alan Gilbert
> ---
> migratio
On Wed, Sep 11, 2019 at 05:41:59PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> This patch uses glib's g_auto mechanism to automatically free
> rcu_read_lock's at the end of the block. Given that humans
> have a habit of forgetting an error path somewhere it's
On Wed, Sep 11, 2019 at 05:42:00PM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
> g_auto infrastrcture (and thus whatever the compilers hooks are) to
> release it on all exits of the block.
>
> No
Now we do all our checking and use a common EXCP_SEMIHOST for
semihosting operations we can make helper code a lot simpler.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
---
v2
- fix re-base conflicts
- hoist EXCP_SEMIHOST check
- comment cleanups
v5
- move CONFIG_TCG ifdefs
We do this for other semihosting calls so we might as well do it for
M-profile as well.
Signed-off-by: Alex Bennée
Reviewed-by: Richard Henderson
---
v2
- update for change to gen_exception_internal_insn API
v3
- update for decode tree
v4
- use !IS_USER
---
target/arm/m_helper.c | 18 ++
As for the other semihosting calls we can resolve this at translate
time.
Signed-off-by: Alex Bennée
---
v2
- update for change to gen_exception_internal_insn API
v3
- update for decode tree, merge T32 & A32 commits
- dropped r-b due to changes
v4
- !IS_USER and !arm_dc_feature(s, ARM_FE
Now we do all our checking at translate time we can make cpu_loop a
little bit simpler. We also introduce a simple linux-user semihosting
test case to defend the functionality. The out-of-tree softmmu based
semihosting tests are still more comprehensive.
Signed-off-by: Alex Bennée
---
linux-user
These were missed in the recent de-tangling so have been updated to be
more actuate. I've also built up ARM_TESTS in a manner similar to
AARCH64_TESTS for better consistency.
Signed-off-by: Alex Bennée
---
tests/tcg/Makefile.target | 7 +--
tests/tcg/aarch64/Makefile.target | 3 ++-
Hi Peter,
I've restored the #ifndef CONFIG_USER_ONLY to ensure A-profile
linux-user still works. I've cleaned up the now unused linux-user code
and added a simple smoke test to make sure we don't break it my
accident. There is a tests/tcg patch at the beginning of the series
which was just fixing
From: "Dr. David Alan Gilbert"
Use the automatic read unlocker in migration/ram.c;
only for the cases where the unlock is at the end of the function.
Signed-off-by: Dr. David Alan Gilbert
---
migration/ram.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff
From: "Dr. David Alan Gilbert"
RCU_READ_LOCK_AUTO takes the rcu_read_lock and then uses glib's
g_auto infrastrcture (and thus whatever the compilers hooks are) to
release it on all exits of the block.
Note this macro has a variable declaration in, and hence is not in
a while loop.
Signed-off-b
From: "Dr. David Alan Gilbert"
This patch uses glib's g_auto mechanism to automatically free
rcu_read_lock's at the end of the block. Given that humans
have a habit of forgetting an error path somewhere it's
best to leave it to the compiler.
In particular:
https://bugzilla.redhat.com/show_bug
From: "Dr. David Alan Gilbert"
Use the automatic read unlocker in migration/rdma.c.
Signed-off-by: Dr. David Alan Gilbert
---
migration/rdma.c | 57 ++--
1 file changed, 11 insertions(+), 46 deletions(-)
diff --git a/migration/rdma.c b/migration/rdm
When running "make distclean" we currently leave a lot of generated
files in the build directory. Fix that.
Signed-off-by: Thomas Huth
---
Makefile | 6 +++---
tests/Makefile.include | 12 +++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Make
On 11.09.19 17:29, Richard Henderson wrote:
> On 9/6/19 3:57 AM, David Hildenbrand wrote:
>> +if (likely(desta.haddr1)) {
>> +memset(desta.haddr1, byte, desta.size1);
>> +} else {
>> +for (i = 0; i < desta.size1; i++) {
>> +helper_ret_stb_mmu(env, desta.vaddr1 +
> -Original Message-
> From: Paul Durrant
> Sent: 11 September 2019 15:36
> To: qemu-devel@nongnu.org; xen-de...@lists.xenproject.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony
> Perard
> Subject: [PATCH 3/3] xen: perform XenDevice clean-up in XenBus watch handler
>
> Cleaning
On 11.09.19 17:18, Richard Henderson wrote:
> On 9/6/19 3:57 AM, David Hildenbrand wrote:
>> 24 and 31-bit address space handling is wrong when it comes to storing
>> back the addresses to the register.
>>
>> Signed-off-by: David Hildenbrand
>> ---
>> target/s390x/helper.h | 2 +-
>> target
On creation, the export's AioContext is set to the same one as the
BlockBackend, while the AioContext in the client QIOChannel is left
untouched.
As a result, when using data-plane, nbd_client_receive_next_request()
schedules coroutines in the IOThread AioContext, while the client's
QIOChannel is
On 11.09.19 17:11, Richard Henderson wrote:
> On 9/6/19 3:57 AM, David Hildenbrand wrote:
>> +l = wrap_length(env, l);
>> if (l > 256) {
>> /* max 256 */
>> l = 256;
>> cc = 3;
>> +} else if (!l) {
>> +return cc;
>> }
>
> Um, wrap_length only ta
On 11.09.19 17:05, Richard Henderson wrote:
> On 9/6/19 3:57 AM, David Hildenbrand wrote:
>> +if (*srclen) {
>> +/* Copy the src array */
>> +len = MIN(len, *srclen);
>> +*destlen -= len;
>> +*srclen -= len;
>> +fast_memmove(env, *dest, *src, len, ra);
>>
On 11.09.19 16:54, Richard Henderson wrote:
> On 9/6/19 3:57 AM, David Hildenbrand wrote:
>> if (dest == src + 1) {
>> fast_memset(env, dest, cpu_ldub_data_ra(env, src, ra), l, ra);
>> -} else if (dest < src || src + l <= dest) {
>> +} else if (!is_destructive_overlap(env, des
On 11.09.19 17:07, Richard Henderson wrote:
> On 9/11/19 10:52 AM, Richard Henderson wrote:
>> The code within Hercules breaks the action at every 2k address boundary --
>> for
>> both src and dest. That's the only way that actually makes sense to me, as
>> otherwise we end up allowing userspace
On 11.09.19 16:40, Richard Henderson wrote:
> On 9/6/19 3:57 AM, David Hildenbrand wrote:
>> We have to zero out unused bits in 24 and 31-bit addressing mode.
>> Provide a new helper.
>>
>> Signed-off-by: David Hildenbrand
>> ---
>> target/s390x/mem_helper.c | 24 ++--
>> 1 fi
On Wed, Sep 11, 2019 at 2:38 PM liuzhiwei wrote:
> From: LIU Zhiwei
>
> Signed-off-by: LIU Zhiwei
> ---
> target/riscv/Makefile.objs | 2 +-
> target/riscv/helper.h | 3 +
> target/riscv/insn32.decode | 5 ++
> target/riscv/insn_trans/trans_rvv
On Wed, Sep 11, 2019 at 04:53:37PM +0200, Cédric Le Goater wrote:
> On 11/09/2019 16:29, Balamuruhan S wrote:
> > add PnvHomer device model to emulate homer memory access
> > for pstate table, occ-sensors, slw, occ static and dynamic
> > values for Power8 and Power9 chips.
> >
> > Signed-off-by: C
Host kernels that expose the KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 capability
allow injection of interrupts along with vcpu ids larger than 255.
Let's encode the vpcu id on 12 bits according to the upgraded KVM_IRQ_LINE
ABI when needed.
Given that we have two callsites that need to assemble
the value for
Temporary header update against 5.3-rc5 + Marc's patch:
"[PATCH] KVM: arm/arm64: vgic: Allow more than 256 vcpus for
KVM_IRQ_LINE"
Signed-off-by: Eric Auger
---
include/standard-headers/asm-x86/bootparam.h | 2 ++
include/standard-headers/asm-x86/kvm_para.h | 1 +
include/standard-headers/lin
Since 4.18, KVM/ARM exposes a KVM_MAX_VCPUS equal to 512. However it was
reported [1] that a VM with more than 256 vcpus cannot be launched. 5.4
is about to fix the situation with 2 patches:
- one upgrade of the KVM_IRQ_LINE API [2] supporting a vcpu id encoded
on 12 bits,
- the reduction of KVM
Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
for ARM. The actual capability to instantiate more than 256 vcpus
was fixed in 5.4 with the upgrade of the KVM_IRQ_LINE ABI to support
vcpu id encoded on 12 bits instead of 8 and a redistributor consuming
a single KVM IO device in
On Wed, 2019-09-11 at 17:36 +0200, Johannes Berg wrote:
> On Wed, 2019-09-11 at 17:31 +0200, Stefan Hajnoczi wrote:
>
> > > +``VHOST_USER_VQ_CALL``
It should also be VRING, not VQ, but I did indeed fix that in v2 already
along with the CALL<->KICK inversion.
So I guess I just have to include the
On Wed, 2019-09-11 at 17:31 +0200, Stefan Hajnoczi wrote:
> > +``VHOST_USER_VQ_CALL``
>
> "call" should be "kick". "kick" is the driver->device request
> submission notification and "call" is the device->driver request
> completion notification.
Ahrg, yes. I confuse this all the time, sorry, wi
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> +if (likely(desta.haddr1)) {
> +memset(desta.haddr1, byte, desta.size1);
> +} else {
> +for (i = 0; i < desta.size1; i++) {
> +helper_ret_stb_mmu(env, desta.vaddr1 + i, byte, oi, ra);
> +}
The only thing perh
On Mon, Sep 2, 2019 at 2:13 PM Johannes Berg wrote:
>
> From: Johannes Berg
>
> For good reason, vhost-user is currently built asynchronously, that
> way better performance can be obtained. However, for certain use
> cases such as simulation, this is problematic.
>
> Consider an event-based simul
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> +l = wrap_length(env, l);
> if (l > 256) {
> /* max 256 */
> l = 256;
> cc = 3;
> +} else if (!l) {
> +return cc;
> }
Um, wrap_length only takes 31 bits.
These insns take 32 bits in 24/31-bit modes.
On Tue, Sep 10, 2019 at 04:16:58PM -0400, Cleber Rosa wrote:
> On Tue, Sep 10, 2019 at 04:43:00PM -0300, Eduardo Habkost wrote:
> > On Tue, Sep 10, 2019 at 08:29:24AM -0400, Cleber Rosa wrote:
> > > On Tue, Sep 10, 2019 at 09:41:20AM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Sep 03, 2019 at
On Wed, 2019-09-11 at 10:07 -0400, Michael S. Tsirkin wrote:
>
> > + #define VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD12
> > + #define VHOST_USER_PROTOCOL_F_IN_BAND_NOTIFICATIONS 13
>
> INFLIGHT so INBAND?
*shrug*, sure
> > + instead of waiting for the call; however, if the protocol featu
On Wed, Sep 11, 2019 at 2:38 PM liuzhiwei wrote:
> From: LIU Zhiwei
>
> Signed-off-by: LIU Zhiwei
> ---
> target/riscv/cpu_bits.h | 15
> target/riscv/csr.c | 65
> ++---
> 2 files changed, 76 insertions(+), 4 deletions(-)
>
> diff
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> 24 and 31-bit address space handling is wrong when it comes to storing
> back the addresses to the register.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/helper.h | 2 +-
> target/s390x/insn-data.def | 2 +-
> target/s390x/mem_hel
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> Although we basically ignore the index all the time for CONFIG_USER_ONLY,
> let's simply skip all the checks and always return MMU_USER_IDX in
> cpu_mmu_index() and get_mem_index().
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/cpu.h
We need to lock qcow2 mutex on accessing in-image metadata, especially
on updating this metadata. Let's implement it.
v2:
fix uninitialized variable in 03, found by Patchew
Vladimir Sementsov-Ogievskiy (3):
block: move bdrv_can_store_new_dirty_bitmap to block/dirty-bitmap.c
block/dirty-bitma
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> Let's perform the documented checks.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mem_helper.c | 12
> 1 file changed, 12 insertions(+)
Reviewed-by: Richard Henderson
r~
On Wed, Sep 11, 2019 at 11:13 AM Johannes Berg
wrote:
> On Wed, 2019-09-11 at 09:35 +0200, Stefan Hajnoczi wrote:
> > On Tue, Sep 10, 2019 at 05:14:36PM +0200, Johannes Berg wrote:
> > > On Tue, 2019-09-10 at 17:03 +0200, Stefan Hajnoczi wrote:
> > I'm suggesting this because it seems like a clean
On Wed, Sep 11, 2019 at 2:36 PM liuzhiwei wrote:
> From: LIU Zhiwei
>
> Signed-off-by: LIU Zhiwei
> ---
> target/riscv/cpu.c | 6 +-
> target/riscv/cpu.h | 2 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index f8d07bd..9f93
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> +if (*srclen) {
> +/* Copy the src array */
> +len = MIN(len, *srclen);
> +*destlen -= len;
> +*srclen -= len;
> +fast_memmove(env, *dest, *src, len, ra);
> +*src = wrap_address(env, *src + len);
> +
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> Bit position 32-55 of general register 0 must be zero.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mem_helper.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Richard Henderson
r~
The "latency" parameter wasn't covered by the documentation.
Signed-off-by: Stefan Hajnoczi
---
How is this parameter related to buffer-length?
---
qemu-options.hx | 4
1 file changed, 4 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.hx
index a4f9f74f52..82154cecf8 100644
--- a/
On Wed, Sep 11, 2019 at 09:22:39AM -0400, Richard Henderson wrote:
> I would be hesitant to call this just "lduw_be"; I think that's confusing when
> it's calling lduw_be_p. But perhaps "wrap_*" or "wide_*"?
Agree, some hamming distance is needed.
"wrap_*", "wide_*", or "direct_*" all works for
Patchew URL:
https://patchew.org/QEMU/20190911134539.25650-1-johan...@sipsolutions.net/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [Qemu-devel] [RFC v2 0/2] vhost-user: in-band notifications
Message-id: 20190911134539.25650-1-joha
07.08.2019 19:27, John Snow wrote:
>
>
> On 8/6/19 12:19 PM, Vladimir Sementsov-Ogievskiy wrote:
>> 06.08.2019 19:09, Max Reitz wrote:
>>> On 06.08.19 17:26, Vladimir Sementsov-Ogievskiy wrote:
hbitmap_reset has an unobvious property: it rounds requested region up.
It may provoke bugs,
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> We have to mask of any unused bits. While at it, document what exactly is
> missing.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mem_helper.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
Reviewed-by: Richard Hend
handle_alloc() tries to find as many contiguous clusters that need
copy-on-write as possible in order to allocate all of them at the same
time.
However, compressed clusters are only overwritten one by one, so let's
say that we have an image with 1024 consecutive compressed clusters:
qemu-img c
qmp_block_dirty_bitmap_add and do_block_dirty_bitmap_remove do acquire
aio context since 0a6c86d024c52b. But this is not enough: we also must
lock qcow2 mutex when access in-image metadata. Especially it concerns
freeing qcow2 clusters.
To achieve this, move qcow2_can_store_new_dirty_bitmap and
qc
On Tue, Sep 10, 2019 at 09:43:53PM -0400, Richard Henderson wrote:
> Handle bswap on ram directly in load/store_helper. This fixes a
> bug with the previous implementation in that one cannot use the
> I/O path for RAM.
>
> Fixes: a26fc6f5152b47f1
> Signed-off-by: Richard Henderson
> ---
> inclu
On 9/11/19 10:52 AM, Richard Henderson wrote:
> The code within Hercules breaks the action at every 2k address boundary -- for
> both src and dest. That's the only way that actually makes sense to me, as
> otherwise we end up allowing userspace to read/write into a page without
> permission. Whic
Fixes: f0b3d811529 ("audio: -audiodev command line option: documentation")
Signed-off-by: Stefan Hajnoczi
---
qemu-options.hx | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index bbfd936d29..a4f9f74f52 100644
--- a/qemu-options.hx
+++ b/q
It's more comfortable to not deal with local_err.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block/qcow2.h| 5 ++---
include/block/block_int.h| 6 +++---
include/block/dirty-bitmap.h | 5 ++---
block/dirty-bitmap.c | 9 +
block/qcow2-bitmap.c
On 11/09/2019 16:29, Balamuruhan S wrote:
> There were few trailing comments after `/*` instead in
> new line and line more than 80 character, these fixes are
> trivial and doesn't change any logic in code.
>
> Signed-off-by: Balamuruhan S
Reviewed-by: Cédric Le Goater
Thanks,
C.
> ---
> h
Small fixes to the -audiodev documentation.
Stefan Hajnoczi (2):
audio: fix buffer-length typo in documentation
audio: add -audiodev pa,in|out.latency= to documentation
qemu-options.hx | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
--
2.21.0
On 9/11/19 10:06 AM, David Gibson wrote:
> On Wed, Aug 21, 2019 at 06:33:33PM +0200, Damien Hedde wrote:
>> This commit defines an interface allowing multi-phase reset. This aims
>> to solve a problem of the actual single-phase reset (built in
>> DeviceClass and BusClass): reset behavior is depe
block/dirty-bitmap.c seems to be more appropriate for it and
bdrv_remove_persistent_dirty_bitmap already in it.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
block.c | 22 --
block/dirty-bitmap.c | 22 ++
2 files changed, 22 insertions(+), 2
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> Process max 2k bytes at a time, writing back registers between the
> accesses. The instruction is interruptible.
> "For operands longer than 2K bytes, access exceptions are not
> recognized for locations more than 2K bytes beyond the current loc
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> Perform the checks documented in the PoP.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mem_helper.c | 7 +++
> 1 file changed, 7 insertions(+)
Reviewed-by: Richard Henderson
r~
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> if (dest == src + 1) {
> fast_memset(env, dest, cpu_ldub_data_ra(env, src, ra), l, ra);
> -} else if (dest < src || src + l <= dest) {
> +} else if (!is_destructive_overlap(env, dest, src, l)) {
> fast_memmove(env, dest, s
Version 0.4 of the hypervisor spec no longer talks about swapping
registers. Instead when running in VS-mode some of the supervisor registers
are "aliased" and actually refer to alternate versions. Implementations are
of course still allowed to do swapping internally if desired, but it adds
complex
On 11/09/2019 16:29, Balamuruhan S wrote:
> add PnvHomer device model to emulate homer memory access
> for pstate table, occ-sensors, slw, occ static and dynamic
> values for Power8 and Power9 chips.
>
> Signed-off-by: Cédric Le Goater
I don't remember this "Signed-off-by". Please remove it.
A
Add a helper for creating GPIO chips that merely forward all operations
to other GPIOs.
This will be used by the GPIO Aggregator.
Signed-off-by: Geert Uytterhoeven
---
I expect this can be used by the GPIO inverter, too, after adding an
"invert" flag, or a filter function that checks which offse
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> We have to zero out unused bits in 24 and 31-bit addressing mode.
> Provide a new helper.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mem_helper.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
Review
Hi all,
GPIO controllers are exported to userspace using /dev/gpiochip*
character devices. Access control to these devices is provided by
standard UNIX file system permissions, on an all-or-nothing basis:
either a GPIO controller is accessible for a user, or it is not.
Currently no mechan
On Wed, Sep 11, 2019 at 2:35 PM liuzhiwei wrote:
> From: LIU Zhiwei
>
> Signed-off-by: LIU Zhiwei
> ---
> target/riscv/cpu.h | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 0adb307..c992b1d 100644
> --- a/ta
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> We use the marker "-1" for "no exception". s390_cpu_do_interrupt() might
> get confused by that.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mem_helper.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Richar
Export the gpiod_request() and gpiod_free() symbols, so modular GPIO
library code can make use of these functions.
Signed-off-by: Geert Uytterhoeven
---
ERROR: "gpiod_free" [drivers/gpio/gpiolib-fwd.ko] undefined!
ERROR: "gpiod_request" [drivers/gpio/gpiolib-fwd.ko] undefined!
Alternatives:
-
> Note that the RCU thread is expected to sit most of the time doing
> nothing, so I don't think this matters.
Agreed.
> Zhengui's theory that notify_me doesn't work properly on ARM is more
> promising, but he couldn't provide a clear explanation of why he thought
> notify_me is involved. In
Gentle ping
On Tue, Aug 27, 2019, 11:24 Sam Eiderman wrote:
> v1:
>
> Non-standard logical geometries break under QEMU.
>
> A virtual disk which contains an operating system which depends on
> logical geometries (consistent values being reported from BIOS INT13
> AH=08) will most likely break un
From: Philippe Mathieu-Daudé
When 'system_reset' is called, the main loop clear the memory
region cache before the BH has a chance to execute. Later when
the deferred function is called, some assumptions that were
made when scheduling them are no longer true when they actually
execute.
This is w
On 9/6/19 3:57 AM, David Hildenbrand wrote:
> We'll have to zero-out unused bit positions, so amke sure to write the
> addresses back.
>
> Signed-off-by: David Hildenbrand
> ---
> target/s390x/mem_helper.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
Reviewed-b
The following changes since commit cc6613e244e86c66f83467eab5284825d7057cea:
Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request'
into staging (2019-09-03 11:06:09 +0100)
are available in the Git repository at:
https://github.com/stefanha/qemu.git tags/block-pull-reques
This patch uses the XenWatchList abstraction to add a separate watch list
for each device. This is more scalable than walking a single notifier
list for all watches and is also necessary to implement a bug-fix in a
subsequent patch.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anth
Make gpio_name_to_desc() global, and export its symbol, so modular GPIO
driver can make use of this function.
This will be used by the GPIO Aggregator.
Signed-off-by: Geert Uytterhoeven
---
drivers/gpio/gpiolib.c | 3 ++-
drivers/gpio/gpiolib.h | 1 +
2 files changed, 3 insertions(+), 1 deletio
Cleaning up offine XenDevice objects directly in
xen_device_backend_changed() is dangerous as xen_device_unrealize() will
modify the watch list that is being walked. Even the QLIST_FOREACH_SAFE()
used in notifier_list_notify() is insufficient as *two* notifiers (for
the frontend and backend watches
GPIO controllers are exported to userspace using /dev/gpiochip*
character devices. Access control to these devices is provided by
standard UNIX file system permissions, on an all-or-nothing basis:
either a GPIO controller is accessible for a user, or it is not.
Currently no mechanism exists to con
Export the gpiochip_get_desc() symbol, so modular GPIO driver can make
use of this function again.
This is a partial revert of commit 1bd6b601fe196b6f ("gpio: make
gpiochip_get_desc() gpiolib-private").
Signed-off-by: Geert Uytterhoeven
---
ERROR: "gpiochip_get_desc" [drivers/gpio/gpio-aggregato
Xenstore watch call-backs are already abstracted away from XenBus using
the XenWatch data structure but the associated NotifierList manipulation
and file handle registation is still open coded in various xen_bus_...()
functions.
This patch creates a new XenWatchList data structure to allow these
in
101 - 200 of 377 matches
Mail list logo
