On Thu, Jul 30, 2020 at 12:17:32AM +0200, Emanuele Giuseppe Esposito wrote:
> pci_dma_rw currently always returns 0, regardless
> of the result of dma_memory_rw. Adjusted to return
> the correct value.
>
> Signed-off-by: Emanuele Giuseppe Esposito
> ---
> include/hw/pci/pci.h | 3 +--
> 1 file c
On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote:
> This likely affects other, less popular host architectures as well.
> Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from
> which VIRTIO_MEM_MIN_BLOCK_SIZE is derived) define to a variable of
> type uintptr, which i
On 30.07.20 09:49, Stefano Garzarella wrote:
> On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote:
>> This likely affects other, less popular host architectures as well.
>> Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from
>> which VIRTIO_MEM_MIN_BLOCK_SIZE is derive
On Thu, Jul 30, 2020 at 09:51:19AM +0200, David Hildenbrand wrote:
> On 30.07.20 09:49, Stefano Garzarella wrote:
> > On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote:
> >> This likely affects other, less popular host architectures as well.
> >> Less common host architectures under linu
On Tue, Jul 28, 2020 at 4:05 AM Alistair Francis
wrote:
> On Mon, Jul 27, 2020 at 12:54 PM Palmer Dabbelt
> wrote:
> >
> > On Wed, 22 Jul 2020 02:15:24 PDT (-0700), frank.ch...@sifive.com wrote:
> > > From: Frank Chang
> > >
> > > Signed-off-by: Frank Chang
> > > ---
> > > target/riscv/cpu.c
On 30.07.20 09:58, Stefano Garzarella wrote:
> On Thu, Jul 30, 2020 at 09:51:19AM +0200, David Hildenbrand wrote:
>> On 30.07.20 09:49, Stefano Garzarella wrote:
>>> On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote:
This likely affects other, less popular host architectures as well
Christophe de Dinechin writes:
> On 2020-07-29 at 13:53 CEST, Markus Armbruster wrote...
>> Christophe de Dinechin writes:
>>
>>> On 2020-07-27 at 10:23 CEST, Markus Armbruster wrote...
Christophe de Dinechin writes:
> On 2020-07-23 at 16:06 CEST, Markus Armbruster wrote...
>>
Paolo Bonzini writes:
> On 29/07/20 09:39, Markus Armbruster wrote:
>> Taking a step back, I disagree with the notion that assertions should be
>> avoided just because we have an Error **. A programming error doesn't
>> become less wrong, and continuing when the program is in disorder
>> doesn't
On Thu, 30 Jul 2020 at 02:56, Kaige Li wrote:
>
> When I compile qemu with such as:
>
> git clone https://git.qemu.org/git/qemu.git
> cd qemu
> git submodule init
> git submodule update --recursive
> ./configure
> make
>
> There is error log:
>
> /home/LiKaige/qemu/target/arm/translate-a64.c: In f
On Wed, 29 Jul 2020 at 23:19, Emanuele Giuseppe Esposito
wrote:
>
> pci_dma_rw currently always returns 0, regardless
> of the result of dma_memory_rw. Adjusted to return
> the correct value.
>
> Signed-off-by: Emanuele Giuseppe Esposito
We also have the equivalent patch from Klaus Jensen back i
On 30/07/2020 09:41, Stefano Garzarella wrote:
On Thu, Jul 30, 2020 at 12:17:32AM +0200, Emanuele Giuseppe Esposito wrote:
pci_dma_rw currently always returns 0, regardless
of the result of dma_memory_rw. Adjusted to return
the correct value.
Signed-off-by: Emanuele Giuseppe Esposito
---
On Wed, 2020-07-29 at 22:08 +0200, Klaus Jensen wrote:
> On Jul 29 21:45, Maxim Levitsky wrote:
> > On Wed, 2020-07-29 at 15:37 +0200, Klaus Jensen wrote:
> > > On Jul 29 13:43, Maxim Levitsky wrote:
> > > > On Mon, 2020-07-06 at 08:12 +0200, Klaus Jensen wrote:
> > > > > +DEFINE_PROP_UINT8("ae
On Thu, 30 Jul 2020 at 08:42, Stefano Garzarella wrote:
> I agree that it is better to return the dma_memory_rw() return value, but
> at first look, no one seems to check the return value of pci_dma_rw(),
> pci_dma_read(), andpci_dma_write().
>
> Should we make them void?
In general code (eg devi
On Wed, Jul 29, 2020 at 06:14:07PM -0400, Vivek Goyal wrote:
> Right now we create lock/pid file in /usr/local/var/... and unprivliged
> user does not have access to create files there.
>
> So create this file in per user cache dir as queried as specified
> by environment variable XDG_RUNTIME_DIR.
Andrea Bolognani writes:
> The various schemas included in QEMU use a JSON-based format which
> is, however, strictly speaking not valid JSON.
>
> As a consequence, when vim tries to apply syntax highlight rules
> for JSON (as guessed from the file name), the result is an unreadable
> mess which
Signed-off-by: Markus Armbruster
---
qapi/block-core.json | 24
qapi/ui.json | 4 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index ab7bf3c612..bdcc8e5f9f 100644
--- a/qapi/block-core.json
+++
Peter Maydell writes:
> In commit 176d2cda0dee9f4 we added the @die-id field
> to the CpuInstanceProperties struct, but in the process
> accidentally removed the newline between the doc-comment
> lines for @core-id and @thread-id.
>
> Put the newline back in; this fixes a misformatting in the
> g
On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote:
> Andrea Bolognani writes:
>
> > The various schemas included in QEMU use a JSON-based format which
> > is, however, strictly speaking not valid JSON.
> >
> > As a consequence, when vim tries to apply syntax highlight rules
> > fo
On Tue, 28 Jul 2020 21:51:33 -0300
Thiago Jung Bauermann wrote:
> Hi,
>
> Cornelia Huck writes:
>
> > On Wed, 22 Jul 2020 23:56:57 -0300
> > Thiago Jung Bauermann wrote:
> >
> >> Instead of setting CPUState::halted to 1 in s390_cpu_initfn(), use the
> >> start-powered-off property which mak
For "fmax/fmin ft0, ft1, ft2" and if one of the inputs is sNaN,
The original logic
return NaN and set invalid flag if ft1 == sNaN || ft2 == sNan
The alternative path
set invalid flag if ft1 == sNaN || ft2 == sNaN
return NaN if ft1 == sNaN && ft2 == sNaN
The ieee754 spec allows
These patches are separated from riscv vector extension 0.9 patchset.
The set includes
1. alternative NaN handlding
2. float16 comparision APIs.
3. float16 to int8/uint8 conversion APIs
Chih-Min Chao (1):
softfloat: add APIs to handle alternative sNaN propagation
Frank Chang (1):
so
From: Kito Cheng
Implement them in softfloat and remove local version in riscv
Signed-off-by: Kito Cheng
Signed-off-by: Chih-Min Chao
Acked-by: Alex Bennée
---
include/fpu/softfloat.h | 41 +
target/riscv/vector_helper.c | 25 -
From: Frank Chang
Signed-off-by: Frank Chang
Reviewed-by: Alex Bennée
---
fpu/softfloat.c | 34 ++
include/fpu/softfloat.h | 8
2 files changed, 42 insertions(+)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 4466ece..c700a39 100644
---
Paolo Bonzini writes:
> On 29/07/20 15:18, Markus Armbruster wrote:
>>> Even code riddled by backwards-compatibility special cases, such as
>>> -accel and -machine, can share code between themselves and -object to
>>> some extent; this is thanks to functions such as object_property_parse,
>>> who
On Mittwoch, 29. Juli 2020 10:12:33 CEST Christian Schoenebeck wrote:
> The newly added function v9fs_co_readdir_many() retrieves multiple
> directory entries with a single fs driver request. It is intended to
> replace uses of v9fs_co_readdir(), the latter only retrives a single
> directory entry
On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote:
>
> From: Klaus Jensen
>
> This is preparatory to subsequent patches that change how QSGs/IOVs are
> handled. It is important that the qsg and iov members of the NvmeRequest
> are initially zeroed.
>
> Signed-off-by: Klaus Jensen
> Reviewed-by:
On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote:
>
> From: Klaus Jensen
>
> Remove the has_sg member from NvmeRequest since it's redundant.
>
> Signed-off-by: Klaus Jensen
Looks better than the previous one to me.
Reviewed-by: Minwoo Im
On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote:
>
> From: Klaus Jensen
>
> Make sure the request iov is destroyed before reuse; fixing a memory
> leak.
>
> Signed-off-by: Klaus Jensen
Looks good to me and Thanks for splitting this up.
Reviewed-by: Minwoo Im
On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote:
>
> From: Klaus Jensen
>
> Add tracing to nvme_map_prp.
>
> Signed-off-by: Klaus Jensen
> ---
> hw/block/nvme.c | 2 ++
> hw/block/trace-events | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/hw/block/nvme.c b/hw/block/nvme.c
On Thu, Jul 30, 2020 at 7:06 AM Klaus Jensen wrote:
>
> From: Klaus Jensen
>
> Introduce the nvme_map helper to remove some noise in the main nvme_rw
> function.
>
> Signed-off-by: Klaus Jensen
> Reviewed-by: Maxim Levitsky
> ---
> hw/block/nvme.c | 13 ++---
> 1 file changed, 10 inser
On Wed, Jul 29, 2020 at 03:02:22PM +0200, Halil Pasic wrote:
> As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1)
> reads one past of the end of ms->loadparm, so g_memdup() can not be used
> here.
>
> Let's use malloc and memcpy instead!
>
> Fixes: d664548328 ("s390x/s390-v
On Wed, 29 Jul 2020 15:02:22 +0200
Halil Pasic wrote:
> As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1)
> reads one past of the end of ms->loadparm, so g_memdup() can not be used
> here.
>
> Let's use malloc and memcpy instead!
Hm, an alternative would be to use g_strn
On 2020-07-30 at 10:13 CEST, Markus Armbruster wrote...
> Christophe de Dinechin writes:
>
>> On 2020-07-29 at 13:53 CEST, Markus Armbruster wrote...
>>> Christophe de Dinechin writes:
>>>
On 2020-07-27 at 10:23 CEST, Markus Armbruster wrote...
> Christophe de Dinechin writes:
>
>
On 20-07-30 00:06:37, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Since clean up of the request qsg/iov is now always done post-use, there
> is no need to use a stack-allocated qsg/iov in nvme_dma_prp.
>
> Signed-off-by: Klaus Jensen
> Acked-by: Keith Busch
> Reviewed-by: Maxim Levitsky
Rev
On 20-07-30 00:06:38, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Since nvme_map_prp always operate on the request-scoped qsg/iovs, just
> pass a single pointer to the NvmeRequest instead of two for each of the
> qsg and iov.
>
> Suggested-by: Minwoo Im
> Signed-off-by: Klaus Jensen
> ---
>
On 20-07-30 00:06:36, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Always destroy the request qsg/iov at the end of request use.
>
> Signed-off-by: Klaus Jensen
> ---
> hw/block/nvme.c | 52 -
> 1 file changed, 21 insertions(+), 31 deletions(-)
>
On Thu, Jul 30, 2020 at 10:50:43AM +0200, Emanuele Giuseppe Esposito wrote:
>
>
> On 30/07/2020 09:41, Stefano Garzarella wrote:
> > On Thu, Jul 30, 2020 at 12:17:32AM +0200, Emanuele Giuseppe Esposito wrote:
> > > pci_dma_rw currently always returns 0, regardless
> > > of the result of dma_memor
On Thu, 2020-07-30 at 00:06 +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Remove the has_sg member from NvmeRequest since it's redundant.
>
> Signed-off-by: Klaus Jensen
Reviewed-by: Maxim Levitsky
Best regards,
Maxim Levitsky
> ---
> hw/block/nvme.c | 7 ++-
> hw/block/
On Thu, 2020-07-30 at 00:06 +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Make sure the request iov is destroyed before reuse; fixing a memory
> leak.
>
> Signed-off-by: Klaus Jensen
> ---
> hw/block/nvme.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/block/nvme.c b/h
On Thu, 2020-07-30 at 00:06 +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Add tracing to nvme_map_prp.
>
> Signed-off-by: Klaus Jensen
> ---
> hw/block/nvme.c | 2 ++
> hw/block/trace-events | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/hw/block/nvme.c b/hw/block/nvme
On Thu, Jul 30, 2020 at 09:58:21AM +0100, Peter Maydell wrote:
> On Thu, 30 Jul 2020 at 08:42, Stefano Garzarella wrote:
> > I agree that it is better to return the dma_memory_rw() return value, but
> > at first look, no one seems to check the return value of pci_dma_rw(),
> > pci_dma_read(), andp
On Tue, 28 Jul 2020 at 20:57, Richard Henderson
wrote:
>
> The definition of top_bit used in this function is one higher
> than that used in the Arm ARM psuedo-code, which put the error
> indication at top_bit - 1 at the wrong place, which meant that
> it wasn't visible to Auth.
>
> Fixing the def
On Thu, 2020-07-30 at 19:31 +0900, Minwoo Im wrote:
> On 20-07-30 00:06:36, Klaus Jensen wrote:
> > From: Klaus Jensen
> >
> > Always destroy the request qsg/iov at the end of request use.
> >
> > Signed-off-by: Klaus Jensen
> > ---
> > hw/block/nvme.c | 52
On Thu, 2020-07-30 at 00:06 +0200, Klaus Jensen wrote:
> From: Klaus Jensen
>
> Since nvme_map_prp always operate on the request-scoped qsg/iovs, just
> pass a single pointer to the NvmeRequest instead of two for each of the
> qsg and iov.
>
> Suggested-by: Minwoo Im
> Signed-off-by: Klaus Jens
Le jeu. 30 juil. 2020 03:00, David Gibson a
écrit :
> On Tue, Jul 28, 2020 at 09:56:36PM -0300, Thiago Jung Bauermann wrote:
> >
> > Thiago Jung Bauermann writes:
> >
> > > The ARM code has a start-powered-off property in ARMCPU, which is a
> > > subclass of CPUState. This property causes arm_cp
On Jul 30 19:31, Minwoo Im wrote:
> On 20-07-30 00:06:36, Klaus Jensen wrote:
> > From: Klaus Jensen
> >
> > Always destroy the request qsg/iov at the end of request use.
> >
> > Signed-off-by: Klaus Jensen
> > ---
> > hw/block/nvme.c | 52 -
> >
On 30/07/20 12:03, Markus Armbruster wrote:
> qdev C layer:
>
> frob->prop = 42;
>
> Least cognitive load.
>
> QOM has no C layer.
Not really, a QOM object is totally free to do frob->prop = 42. And
just like we didn't do that outside device implementation in qdev as our
tithe to the Churc
Fixed in commit b418d2656112174c; this will be in QEMU 5.1.
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1886343
Title:
configure ha
On 07/30/2020 04:44 PM, Peter Maydell wrote:
On Thu, 30 Jul 2020 at 02:56, Kaige Li wrote:
When I compile qemu with such as:
git clone https://git.qemu.org/git/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure
make
There is error log:
/home/LiKaige/qemu/target
On Thu, 30 Jul 2020 at 12:19, Kaige Li wrote:
>
> On 07/30/2020 04:44 PM, Peter Maydell wrote:
>
> > On Thu, 30 Jul 2020 at 02:56, Kaige Li wrote:
> >> When I compile qemu with such as:
> >>
> >> git clone https://git.qemu.org/git/qemu.git
> >> cd qemu
> >> git submodule init
> >> git submodule u
On Thu, 30 Jul 2020 12:26:56 +0200
Cornelia Huck wrote:
> On Wed, 29 Jul 2020 15:02:22 +0200
> Halil Pasic wrote:
>
> > As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1)
> > reads one past of the end of ms->loadparm, so g_memdup() can not be used
> > here.
> >
> > Let's
** Changed in: qemu
Status: New => Incomplete
** Changed in: qemu
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1884728
Title:
facing build error for qe
On Tue, 2020-07-07 at 21:15 +0200, Klaus Jensen wrote:
> On Jul 7 19:27, Maxim Levitsky wrote:
> > On Wed, 2020-07-01 at 14:48 -0700, Andrzej Jakowski wrote:
> > > This patch sets CMBS bit in controller capabilities register when user
> > > configures NVMe driver with CMB support, so capabilites a
The warnings aren't a problem for QEMU because we don't expose these
functions as public ABI, so the whole compile will be consistently built
with the same compiler version. So we added -Wno-psabi in commit
bac8d222a19f4a30d to silence the compiler here.
** Changed in: qemu
Status: New =>
** Tags added: arm
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1879587
Title:
Register number in ESR is incorrect for certain banked registers when
switching from AA32 to AA64
Status in QEMU:
On Thu, 30 Jul 2020 11:25:06 +0100
Daniel P. Berrangé wrote:
> > /* make a NUL-terminated string */
> > -loadparm_str = g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1);
> > -loadparm_str[sizeof(ms->loadparm)] = 0;
> > +loadparm_str = g_malloc0(sizeof(ms->loadparm) + 1);
> > +
On Wed, 29 Jul 2020 16:22:32 -0500
Babu Moger wrote:
> Igor,
> Sorry. Few more questions.
>
> > -Original Message-
> > From: Igor Mammedov
> > Sent: Wednesday, July 29, 2020 9:12 AM
> > To: Moger, Babu
> > Cc: pbonz...@redhat.com; r...@twiddle.net; qemu-devel@nongnu.org;
> > ehabk...@r
On Thu, 30 Jul 2020 13:25:21 +0200
Halil Pasic wrote:
> On Thu, 30 Jul 2020 12:26:56 +0200
> Cornelia Huck wrote:
>
> > On Wed, 29 Jul 2020 15:02:22 +0200
> > Halil Pasic wrote:
> >
> > > As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1)
> > > reads one past of the e
On 07/30/2020 07:21 PM, Peter Maydell wrote:
On Thu, 30 Jul 2020 at 12:19, Kaige Li wrote:
On 07/30/2020 04:44 PM, Peter Maydell wrote:
On Thu, 30 Jul 2020 at 02:56, Kaige Li wrote:
When I compile qemu with such as:
git clone https://git.qemu.org/git/qemu.git
cd qemu
git submodule init
gi
On Thu, 30 Jul 2020 at 12:28, Kaige Li wrote:
>
> On 07/30/2020 07:21 PM, Peter Maydell wrote:
> > Clang, gcc, OSX clang, something else, and which version number?
> Sorry for that. Gcc version is 4.9.4.
Ah, that makes sense. That's a pretty old version of gcc (it's
almost the oldest we still sup
On Fri, 24 Jul 2020 18:52:59 +0200
Philippe Mathieu-Daudé wrote:
> No MIPS machine uses the ACPI cpu-hotplug feature
> (QEMU implementation is X86 specific).
if I recall correctly we were building it to satisfy symbol dependencies
due to hw/acpi/piix4.c being shared between x86 and mips.
It no
On Wed, 29 Jul 2020 08:09:37 +0300
Maxim Levitsky wrote:
> On Wed, 2020-07-22 at 19:19 +0300, Maxim Levitsky wrote:
> > On Wed, 2020-07-22 at 19:17 +0300, Maxim Levitsky wrote:
> > > Curently it is possible to hotplug a device and then immediatly
> > > hotunplug it before the OS notices, and th
Daniel P. Berrangé writes:
> On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote:
>> Andrea Bolognani writes:
>>
>> > The various schemas included in QEMU use a JSON-based format which
>> > is, however, strictly speaking not valid JSON.
>> >
>> > As a consequence, when vim tries t
When I compile qemu with such as:
git clone https://git.qemu.org/git/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure
make
There is error log:
/home/LiKaige/qemu/target/arm/translate-a64.c: In function ‘disas_ldst’:
/home/LiKaige/qemu/target/arm/translate-a64.c:33
When I compile qemu with such as:
git clone https://git.qemu.org/git/qemu.git
cd qemu
git submodule init
git submodule update --recursive
./configure
make
There is error log:
/home/LiKaige/qemu/hw/virtio/virtio-mem.c: In function
‘virtio_mem_set_block_size’:
/home/LiKaige/qemu/hw/virtio/virtio-
During migration, we release all bitmaps after storing them on disk, as
long as they are (1) stored on disk, (2) not read-only, and (3)
consistent.
(2) seems arbitrary, though. The reason we do not release them is
because we do not write them, as there is no need to; and then we just
forget about
Hi,
When beginning migration, the qcow2 driver syncs all persistent bitmaps
to disk and then releases them. If the user decides to continue on the
source after migration, those bitmaps are re-loaded from the qcow2
image.
However, we only do this for bitmaps that were actively synced, i.e. R/W
bi
On 30.07.20 13:57, Kaige Li wrote:
> When I compile qemu with such as:
>
> git clone https://git.qemu.org/git/qemu.git
> cd qemu
> git submodule init
> git submodule update --recursive
> ./configure
> make
>
> There is error log:
>
> /home/LiKaige/qemu/hw/virtio/virtio-mem.c: In function
> ‘vir
Test migrating from a VM with a persistent bitmap in the backing chain,
and then continuing that VM after the migration
Signed-off-by: Max Reitz
---
tests/qemu-iotests/169 | 64 +-
tests/qemu-iotests/169.out | 4 +--
2 files changed, 65 insertions(+), 3 d
> Hi Minwoo,
>
> The is that on 'exit' we release request resources (like the qsg and
> iov). On 'clear' we initialize the request by clearing the struct. I
> guess I could call it nvme_req_init instead maybe, but really - it is
> clearing it.
Yeah, I just wanted to make it clear to understand mys
On 7/30/20 1:07 AM, Frank Chang wrote:
> So, if it's okay, we can skip RVV v0.9 and bump to RVV v1.0 directly in our
> next version of patchset.
> Which I think may relieve the burden for the community to maintain
> multi-version of vector drafts.
That would be my preference. Thanks,
r~
Paolo Bonzini writes:
> On 30/07/20 12:03, Markus Armbruster wrote:
>> qdev C layer:
>>
>> frob->prop = 42;
>>
>> Least cognitive load.
>>
>> QOM has no C layer.
>
> Not really, a QOM object is totally free to do frob->prop = 42. And
> just like we didn't do that outside device implementa
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> -static inline uint32_t vext_maxsz(uint32_t desc)
> +static inline uint32_t vext_max_elems(uint32_t desc, uint32_t esz, bool
> is_ldst)
> {
> -return simd_maxsz(desc) << vext_lmul(desc);
> +/*
> + * As simd_desc support at most 256,
On Thu, 2020-07-30 at 10:12 +0200, David Hildenbrand wrote:
> On 30.07.20 09:58, Stefano Garzarella wrote:
> > On Thu, Jul 30, 2020 at 09:51:19AM +0200, David Hildenbrand wrote:
> > > On 30.07.20 09:49, Stefano Garzarella wrote:
> > > > On Wed, Jul 29, 2020 at 06:54:38PM -0600, Bruce Rogers wrote:
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> -/*
> - * A simplification for VLMAX
> - * = (1 << LMUL) * VLEN / (8 * (1 << SEW))
> - * = (VLEN << LMUL) / (8 << SEW)
> - * = (VLEN << LMUL) >> (SEW + 3)
> - * = VLEN >> (SEW + 3 - LMUL)
> - */
> static inline uint32_t vext_get_vlmax(RISCVCPU *c
On 30.07.20 14:03, David Hildenbrand wrote:
> On 30.07.20 13:57, Kaige Li wrote:
>> When I compile qemu with such as:
>>
>> git clone https://git.qemu.org/git/qemu.git
>> cd qemu
>> git submodule init
>> git submodule update --recursive
>> ./configure
>> make
>>
>> There is error log:
>>
>> /home/L
Hi all,
I'm doing iperf test on VIRTIO net through vhost-user(HW VDPA).
Find maximal acceptable tx_queue_size/rx_queue_size is 1024.
Basically increase queue size can get better RX rate for my case.
Can we increase the limit(VIRTQUEUE_MAX_SIZE) to 8192 to possibly gain better
performance?
Thank
As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1)
reads one past of the end of ms->loadparm, so g_memdup() can not be used
here.
Let's use g_strndup instead!
Fixes: d664548328 ("s390x/s390-virtio-ccw: fix loadparm property getter")
Fixes: Coverity CID 1431058
Reported-by:
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/insn32.decode | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard Henderson
r~
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/insn32.decode | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard Henderson
r~
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/helper.h | 2 +-
> target/riscv/insn32.decode | 2 +-
> target/riscv/insn_trans/trans_rvv.inc.c | 7 ---
> target/riscv/vector_helper.c
This likely affects other, less popular host architectures as well.
Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from
which VIRTIO_MEM_MIN_BLOCK_SIZE is derived) define to a variable of
type uintptr, which isn't compatible with the format specifier used to
print a user message
On Thu, 30 Jul 2020 at 14:02, Halil Pasic wrote:
>
> As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1)
> reads one past of the end of ms->loadparm, so g_memdup() can not be used
> here.
>
> Let's use g_strndup instead!
>
> Fixes: d664548328 ("s390x/s390-virtio-ccw: fix load
On 30.07.20 15:01, Halil Pasic wrote:
> As pointed out by Peter, g_memdup(ms->loadparm, sizeof(ms->loadparm) + 1)
> reads one past of the end of ms->loadparm, so g_memdup() can not be used
> here.
>
> Let's use g_strndup instead!
>
> Fixes: d664548328 ("s390x/s390-virtio-ccw: fix loadparm propert
On 30.07.20 11:16, Markus Armbruster wrote:
> Signed-off-by: Markus Armbruster
> ---
> qapi/block-core.json | 24
> qapi/ui.json | 4 ++--
> 2 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index a
Andrea Bolognani writes:
> The various schemas included in QEMU use a JSON-based format which
> is, however, strictly speaking not valid JSON.
>
> As a consequence, when vim tries to apply syntax highlight rules
> for JSON (as guessed from the file name), the result is an unreadable
> mess which
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/helper.h | 2 +-
> target/riscv/insn32.decode | 2 +-
> target/riscv/insn_trans/trans_rvv.inc.c | 4 ++--
> target/riscv/vector_helper.c
On Tue, Jul 21, 2020 at 01:48 PM +0100, Stefan Hajnoczi
wrote:
> On Fri, Jul 17, 2020 at 11:29:28AM +0200, Marc Hartmayer wrote:
>> Since virtio existed even before it got standardized, the virtio
>> standard defines the following types of virtio devices:
>>
>> + legacy device (pre-virtio 1.0)
On 7/30/20 1:57 PM, Kaige Li wrote:
> When I compile qemu with such as:
>
> git clone https://git.qemu.org/git/qemu.git
> cd qemu
> git submodule init
> git submodule update --recursive
> ./configure
> make
^ this timeless description is pointless (think at a developer
who read this in 2 weeks, 3
On Thu, 2020-07-30 at 09:56 +0800, Yan Zhao wrote:
> On Wed, Jul 29, 2020 at 12:28:46PM +0100, Sean Mooney wrote:
> > On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> > > On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
> > > > On Mon, 27 Jul 2020 15:24:40 +0800
> > > > Yan Zhao
On 7/30/20 1:57 PM, Kaige Li wrote:
> When I compile qemu with such as:
>
> git clone https://git.qemu.org/git/qemu.git
> cd qemu
> git submodule init
> git submodule update --recursive
> ./configure
> make
Again, timeless information is not useful.
>
> There is error log:
>
> /home/LiKaige/qe
On Thu, 2020-07-30 at 11:41 +0800, Yan Zhao wrote:
> > > >interface_version=3
> >
> > Not much granularity here, I prefer Sean's previous
> > .[.bugfix] scheme.
> >
>
> yes, .[.bugfix] scheme may be better, but I'm not sure if
> it works for a complicated scenario.
> e.g for pv_mode,
> (1) i
On 30.07.20 15:05, Bruce Rogers wrote:
> This likely affects other, less popular host architectures as well.
> Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from
> which VIRTIO_MEM_MIN_BLOCK_SIZE is derived) define to a variable of
> type uintptr, which isn't compatible with th
On Thu, Jul 30, 2020 at 01:51:10PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > modify them so that we can load the
> > files straight into the python intepretor as code, and not parse
> > them as data. I feel unhappy about treating data as co
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/insn32.decode | 6 +++---
> target/riscv/insn_trans/trans_rvv.inc.c | 5 -
> target/riscv/vector_helper.c| 4
> 3 files changed, 7 insertio
On Thu, Jul 30, 2020 at 07:05:19AM -0600, Bruce Rogers wrote:
> This likely affects other, less popular host architectures as well.
> Less common host architectures under linux get QEMU_VMALLOC_ALIGN (from
> which VIRTIO_MEM_MIN_BLOCK_SIZE is derived) define to a variable of
> type uintptr, which i
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/insn32.decode | 2 +-
> target/riscv/vector_helper.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Richard Henderson
r~
On 7/22/20 2:15 AM, frank.ch...@sifive.com wrote:
> From: Frank Chang
>
> Signed-off-by: Frank Chang
> ---
> target/riscv/insn32.decode | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Richard Henderson
r~
On 30/07/20 14:36, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 30/07/20 12:03, Markus Armbruster wrote:
>>> qdev C layer:
>>>
>>> frob->prop = 42;
>>>
>>> Least cognitive load.
>>>
>>> QOM has no C layer.
>>
>> Not really, a QOM object is totally free to do frob->prop = 42. And
On Tue, 28 Jul 2020 at 16:09, Eric Auger wrote:
>
> At the moment each entry in the IOTLB corresponds to a page sized
> mapping (4K, 16K or 64K), even if the page belongs to a mapped
> block. In case of block mapping this unefficiently consumes IOTLB
> entries.
>
> Change the value of the entry so
1 - 100 of 285 matches
Mail list logo
