On Nov 25 10:48, Joel Granados wrote:
> The motivation and description are contained in the last patch in this set.
> Will copy paste it here for convenience:
>
> In order to evaluate write amplification factor (WAF) within the storage
> stack it is important to know the number of bytes wr
On 13/12/2022 08.30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What are you talking about? Of course it does.
The host CPU certainly does, but the virtio de
在 2022/12/9 21:08, Cindy Lu 写道:
1.Skip the check in vhost_vdpa_listener_skipped_section() while
MR is IOMMU, Move this check to vhost_vdpa_iommu_map_notify()
2.Add support for vIOMMU.
So I think the changlog needs some tweak, we need to explain why you
need to do the above.
Add the new
thanks. so now my question is that are these sparsed blocks rewritable? I mean
after deletion of a file and downloading again, will these files be stored on
the sparsed blocks or the number of starting block for write operation will be
after the number of latest sparsed block?
--
You received
On 13/12/22 08:30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What are you talking about? Of course it does.
The host CPU certainly does, but the virtio devi
On 13/12/22 09:03, Thomas Huth wrote:
On 13/12/2022 08.30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What are you talking about? Of course it does.
The hos
On 13/12/2022 09.32, Philippe Mathieu-Daudé wrote:
On 13/12/22 09:03, Thomas Huth wrote:
On 13/12/2022 08.30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What
From: Emanuele Giuseppe Esposito
bdrv_get_allocated_file_size() is categorized as an I/O function, and it
currently doesn't run in a coroutine. We should let it take a graph
rdlock since it traverses the block nodes graph, which however is only
possible in a coroutine.
Therefore turn it into a c
From: Emanuele Giuseppe Esposito
bdrv_eject() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
The only caller of this function is blk_ejec
From: Emanuele Giuseppe Esposito
Since these functions always run in coroutine context, adjust
their name to include "_co_", just like all other BlockDriver callbacks.
No functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
include/block/block_i
From: Emanuele Giuseppe Esposito
bdrv_is_inserted() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
Therefore turn it into a co_wrapper to
From: Emanuele Giuseppe Esposito
bdrv_lock_medium() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
The only caller of this function is bl
From: Emanuele Giuseppe Esposito
Just omit the various 'return' when the return type is void.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
scripts/block-coroutine-wrapper.py | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/sc
From: Emanuele Giuseppe Esposito
BlockDriver->bdrv_io_unplug is categorized as IO callback, and it
currently doesn't run in a coroutine. We should let it take a graph
rdlock since the callback traverses the block nodes graph, which however
is only possible in a coroutine.
The only caller of this
From: Emanuele Giuseppe Esposito
bdrv_get_info() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
Therefore turn it into a co_wrapper to mo
From: Emanuele Giuseppe Esposito
The name is not good, not the least because we are going to convert this
to a generated co_wrapper, which adds a _co infix after the first part
of the name.
No functional change intended.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
From: Emanuele Giuseppe Esposito
In some places we are sure we are always running in a
coroutine, therefore it's useless to call the generated_co_wrapper,
instead call directly the _co_ function.
Signed-off-by: Emanuele Giuseppe Esposito
Signed-off-by: Kevin Wolf
---
block/block-backend.c | 6
From: Emanuele Giuseppe Esposito
BlockDriver->bdrv_io_plug is categorized as IO callback, and it
currently doesn't run in a coroutine. We should let it take a graph
rdlock since the callback traverses the block nodes graph, which however
is only possible in a coroutine.
The only caller of this f
This series converts some IO_CODE() functions to coroutine_fn because
they access the graph and will need to hold the graph lock in the
future. IO_CODE() functions can be called from iothreads, so taking the
graph lock requires the function to run in coroutine context.
Pretty much all of the chang
From: Emanuele Giuseppe Esposito
bdrv_debug_event() is categorized as an I/O function, and it currently
doesn't run in a coroutine. We should let it take a graph rdlock since
it traverses the block nodes graph, which however is only possible in a
coroutine.
Therefore turn it into a co_wrapper_mi
From: Emanuele Giuseppe Esposito
BlockDriver->bdrv_getlength is categorized as IO callback, and it
currently doesn't run in a coroutine. We should let it take a graph
rdlock since the callback traverses the block nodes graph, which however
is only possible in a coroutine.
Therefore turn it into
From: Emanuele Giuseppe Esposito
The only difference is that blk_ checks if the block is available,
but this check is already performed above in blk_check_byte_request().
This is in preparation for the graph rdlock, which will be taken
by both the callers of blk_check_byte_request() and blk_getl
On Mon, 2022-12-12 at 13:13 +, Paul Durrant wrote:
> Ok, this tells me that we are intending to handle Hyper-V enlightenments
> being simultaneously enabled... in which case that MSR above needs to
> move, along with the cpuid leaves. It should be 0x4200 in this case.
Ah, yes. That gets
It seems a little bit weird that the para-virtualized x86 VMWare
devices "vmware-svga" and "vmxnet3" also show up in non-x86 targets.
They are likely pretty useless there (since the guest OSes likely
do not have any drivers for those enabled), so let's change this and
only enable those devices by d
On 13/12/22 10:51, Thomas Huth wrote:
It seems a little bit weird that the para-virtualized x86 VMWare
devices "vmware-svga" and "vmxnet3" also show up in non-x86 targets.
They are likely pretty useless there (since the guest OSes likely
do not have any drivers for those enabled), so let's change
On 13/12/2022 10.51, Thomas Huth wrote:
It seems a little bit weird that the para-virtualized x86 VMWare
devices "vmware-svga" and "vmxnet3" also show up in non-x86 targets.
They are likely pretty useless there (since the guest OSes likely
do not have any drivers for those enabled), so let's chan
On 13/12/2022 11.01, Philippe Mathieu-Daudé wrote:
On 13/12/22 10:51, Thomas Huth wrote:
It seems a little bit weird that the para-virtualized x86 VMWare
devices "vmware-svga" and "vmxnet3" also show up in non-x86 targets.
They are likely pretty useless there (since the guest OSes likely
do not
On 13/12/22 11:13, Thomas Huth wrote:
On 13/12/2022 11.01, Philippe Mathieu-Daudé wrote:
On 13/12/22 10:51, Thomas Huth wrote:
It seems a little bit weird that the para-virtualized x86 VMWare
devices "vmware-svga" and "vmxnet3" also show up in non-x86 targets.
They are likely pretty useless the
The file seems to contain perfectly valid rst syntax already, so
rename it to .rst and wire it up in the index.
Signed-off-by: Thomas Huth
---
docs/interop/index.rst | 1 +
...tate-Pseudo-encoding.txt => vnc-ledstate-pseudo-encoding.rst} | 0
2 files cha
On 11/9/22 00:13, John Johnson wrote:
Add infrastructure needed to receive incoming messages
Signed-off-by: John G Johnson
Signed-off-by: Elena Ufimtseva
Signed-off-by: Jagannathan Raman
---
MAINTAINERS | 1 +
hw/vfio/pci.c | 11 ++
hw/vfio/user-protocol.h | 54 +
On Tue, 13 Dec 2022 00:05:14 +0100
Philippe Mathieu-Daudé wrote:
> Since the device endianness doesn't change at runtime,
> use the cached value instead of evaluating it on each call.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/virtio/virtio-access.h | 44 +++--
Commit f3034ad71f ("qmp: decode feature & status bits in
virtio-status") did not guard all qmp_virtio_feature_map_t
arrays with the corresponding #ifdef'ry used in
qmp_decode_features(). Fix that and reduce the arrays scope
by declaring them static.
Suggested-by: Richard Henderson
Signed-off-by:
These are the uncontroversial patches of my previous series
"hw/virtio: Build most objects as target independent units":
https://lore.kernel.org/qemu-devel/20221212230517.28872-1-phi...@linaro.org/
Housekeeping in hw/virtio/virtio.c:
- Make qmp_virtio_feature_map_t[] arrays static/const
- Extract
The monitor decoders are the only functions using the CONFIG_xxx
definitions declared in the target specific CONFIG_DEVICES header.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/virtio/meson.build | 2 +-
hw/virtio/virtio-qmp.c | 659 +
hw/virtio/virtio-
These config helpers use the target-dependent LD/ST API.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/virtio/meson.build| 1 +
hw/virtio/virtio-config-io.c | 204 +++
hw/virtio/virtio.c | 190
3 files changed, 2
virtio.c uses target_words_bigendian() which is declared in
"hw/core/cpu.h". Add the missing header to avoid when refactoring:
hw/virtio/virtio.c:2451:9: error: implicit declaration of function
'target_words_bigendian' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
if (target_
These arrays are only accessed read-only, move them to .rodata.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/virtio/virtio.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index b35480be8f..f2298bb4
On Tue, Dec 13, 2022 at 9:17 AM Jason Wang wrote:
>
>
> 在 2022/12/9 21:08, Cindy Lu 写道:
> > 1.Skip the check in vhost_vdpa_listener_skipped_section() while
> > MR is IOMMU, Move this check to vhost_vdpa_iommu_map_notify()
> > 2.Add support for vIOMMU.
>
>
> So I think the changlog needs some twea
Since virtio_ss[] is added to specific_ss[], rename it as
specific_virtio_ss[] to make it clearer.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/virtio/meson.build | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/hw/virtio/meson.build
On 12/8/2022 7:30 PM, Chao Peng wrote:
On Thu, Dec 08, 2022 at 04:37:03PM +0800, Xiaoyao Li wrote:
On 12/2/2022 2:13 PM, Chao Peng wrote:
..
Together with the change, a new config HAVE_KVM_RESTRICTED_MEM is added
and right now it is selected on X86_64 only.
From the patch implementation,
On 12/9/2022 2:43 PM, Chenyi Qiang wrote:
On 12/8/2022 2:25 PM, Xiaoyao Li wrote:
Bit[2:0] of CPUID.14H_01H:EAX stands as a whole for the number of INTEL
PT ADDR RANGES. For unsupported value that exceeds what KVM reports,
report it as a whole in mark_unavailable_features() as well.
Maybe t
On 12/9/2022 2:55 PM, Chenyi Qiang wrote:
On 12/8/2022 2:25 PM, Xiaoyao Li wrote:
commit e37a5c7fa459 ("i386: Add Intel Processor Trace feature support")
added the support of Intel PT by making CPUID[14] of PT as fixed feature
set (from ICX) for any CPU model on any host. This truly breaks the
On 2022/12/13 上午4:23, Peter Xu wrote:
On Tue, Dec 13, 2022 at 12:49:39AM +0800, Chuang Xu wrote:
Hi!
Chuang,
In this version:
- rebase to latest upstream.
- add sanity check to address_space_to_flatview().
- postpone the init of the vring cache until migration's loading completes.
Since ther
On 2022/12/13 上午4:18, Peter Xu wrote:
On Tue, Dec 13, 2022 at 12:49:41AM +0800, Chuang Xu wrote:
+bool migration_enable_load_check_delay;
I'm just afraid this is still too hacky.
One thing is because this variable itself to be only set at specific phase
during migration to cover that commit().
On Mon, 12 Dec 2022 11:51:15 +0100
Philippe Mathieu-Daudé wrote:
> tco.c contains the ICH9 implementation of its "total cost
> of ownership". Rename it accordingly to emphasis this is
> a part of the ICH9 model.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: Igor Mammedov
> ---
> Based-
spapr_ovec.c is a device, but it uses target_ulong which is
target specific. The hwaddr type (declared in "exec/hwaddr.h")
better fits hardware addresses.
Change spapr_ovec_parse_vector() to take a hwaddr argument,
allowing the removal of "cpu.h" in a device header.
Signed-off-by: Philippe Mathie
Few changes in hw/ & target/ to reduce the target specificity
of some sPAPR headers.
Philippe Mathieu-Daudé (4):
target/ppc/kvm: Add missing "cpu.h" and "exec/hwaddr.h"
hw/ppc/vof: Do not include the full "cpu.h"
hw/ppc/spapr: Reduce "vof.h" inclusion
hw/ppc/spapr_ovec: Avoid target_ulong
Currently objects including "hw/ppc/spapr.h" are forced to be
target specific due to the inclusion of "vof.h" in "spapr.h".
"spapr.h" only uses a Vof pointer, so doesn't require the structure
declaration. The only place where Vof structure is accessed is in
spapr.c, so include "vof.h" there, and f
kvm_ppc.h is missing various declarations from "cpu.h":
target/ppc/kvm_ppc.h:128:40: error: unknown type name 'CPUPPCState'; did you
mean 'CPUState'?
static inline int kvmppc_get_hypercall(CPUPPCState *env,
^~~
"vof.h" doesn't need the full "cpu.h" to get the target_ulong
definition, including "exec/cpu-defs.h" is enough.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/ppc/vof.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/hw/ppc/vof.h b/include/hw/ppc/vof.h
index f8
Assuming the developers of commits 2c50e26efd ("powerpc: Add
a virtex5 ml507 refdesign board") and 4b387f9ee1 ("ppc: Add
aCube Sam460ex board") were testing on a little-endian setup,
they meant to use const_le32() instead of tswap32() here,
since tswap32() depends on the host endianness.
Signed-of
Hi,
I am trying to remove the tswap() API from system
emulation and replace it by more meaningful calls,
because tswap depends on the host endianness, and
this detail should be irrelevant from the system
emulation PoV.
In this RFC series I'm trying to convert the PPC
calls.
Any help in understan
This partly revert commit d48751ed4f ("xilinx-ethlite:
Simplify byteswapping to/from brams") which states the
packet data is stored in big-endian.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/net/xilinx_ethlite.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/n
The tswap64() calls introduced in commit 4be21d561d ("pseries:
savevm support for pseries machine") are used to store the HTAB
in the migration stream (see savevm_htab_handlers) and are in
big-endian format.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/ppc/spapr.c | 9 +
1 file changed,
Am 08.12.22 um 10:44 schrieb Pierre Morel:
The migration can only take place if both source and destination
of the migration both use or both do not use the CPU topology
facility.
We indicate a change in topology during migration postload for the
case the topology changed between source and dest
Hi!
In this version:
- move virtio_load_check_delay() from virtio_memory_listener_commit() to
virtio_vmstate_change().
- add delay_check flag to VirtIODevice to make sure virtio_load_check_delay()
will be called when delay_check is true.
Please review, Chuang.
[v2]
- rebase to latest ups
Before using any flatview, sanity check we're not during a memory
region transaction or the map can be invalid.
Signed-off-by: Chuang Xu
---
include/exec/memory.h | 9 +
softmmu/memory.c | 1 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/exec/memory.h b/inc
Delay checks in virtio_load() to avoid possible address_space_to_flatview() call
during memory region's begin/commit.
Signed-off-by: Chuang Xu
---
hw/virtio/virtio.c | 37 +++--
include/hw/virtio/virtio.h | 2 ++
2 files changed, 29 insertions(+), 10 dele
The duration of loading non-iterable vmstate accounts for a significant
portion of downtime (starting with the timestamp of source qemu stop and
ending with the timestamp of target qemu start). Most of the time is spent
committing memory region changes repeatedly.
This patch packs all the changes
Am 12.12.22 um 11:17 schrieb Thomas Huth:
On 12/12/2022 11.10, Pierre Morel wrote:
On 12/12/22 10:07, Thomas Huth wrote:
On 12/12/2022 09.51, Pierre Morel wrote:
On 12/9/22 14:32, Thomas Huth wrote:
On 08/12/2022 10.44, Pierre Morel wrote:
Hi,
Implementation discussions
=
On 11/9/22 00:13, John Johnson wrote:
Also negotiate protocol version with remote server
Signed-off-by: Jagannathan Raman
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
---
hw/vfio/pci.c | 15 ++
hw/vfio/pci.h | 1 +
hw/vfio/user-protocol.h | 62 +
Am 12.12.22 um 11:01 schrieb Pierre Morel:
On 12/9/22 15:45, Cédric Le Goater wrote:
On 12/8/22 10:44, Pierre Morel wrote:
Hi,
Implementation discussions
==
CPU models
--
Since the S390_FEAT_CONFIGURATION_TOPOLOGY is already in the CPU model
for old QEMU
On Tue, 13 Dec 2022 at 12:52, Philippe Mathieu-Daudé wrote:
>
> The tswap64() calls introduced in commit 4be21d561d ("pseries:
> savevm support for pseries machine") are used to store the HTAB
> in the migration stream (see savevm_htab_handlers) and are in
> big-endian format.
I think they're rea
On Tue, 13 Dec 2022 at 12:52, Philippe Mathieu-Daudé wrote:
>
> This partly revert commit d48751ed4f ("xilinx-ethlite:
> Simplify byteswapping to/from brams") which states the
> packet data is stored in big-endian.
>
> Signed-off-by: Philippe Mathieu-Daudé
> @@ -102,8 +102,8 @@ eth_read(void *op
On Tue, 2022-12-13 at 14:41 +0100, Christian Borntraeger wrote:
>
> Am 12.12.22 um 11:17 schrieb Thomas Huth:
> > On 12/12/2022 11.10, Pierre Morel wrote:
> > >
> > >
> > > On 12/12/22 10:07, Thomas Huth wrote:
> > > > On 12/12/2022 09.51, Pierre Morel wrote:
> > > > >
> > > > >
> > > > > On 1
Am 13.12.22 um 14:57 schrieb Janis Schoetterl-Glausch:
On Tue, 2022-12-13 at 14:41 +0100, Christian Borntraeger wrote:
Am 12.12.22 um 11:17 schrieb Thomas Huth:
On 12/12/2022 11.10, Pierre Morel wrote:
On 12/12/22 10:07, Thomas Huth wrote:
On 12/12/2022 09.51, Pierre Morel wrote:
On
On 11/9/22 00:13, John Johnson wrote:
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
---
hw/vfio/pci.c | 15 ++
hw/vfio/user-protocol.h | 13
hw/vfio/user.c | 55 +
On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
Hi,
In the last years we had few discussions on "simplifying" QEMU (system
emulation / virtualization), in particular for the "management layer".
Some of us are interested in having QEMU able to dynamically create
machine models. Mark Burton's
On Tue, Dec 13, 2022 at 01:53:15PM +, Peter Maydell wrote:
> On Tue, 13 Dec 2022 at 12:52, Philippe Mathieu-Daudé
> wrote:
> >
> > This partly revert commit d48751ed4f ("xilinx-ethlite:
> > Simplify byteswapping to/from brams") which states the
> > packet data is stored in big-endian.
> >
> >
On Tue, 13 Dec 2022 at 09:08, Philippe Mathieu-Daudé wrote:
>
> On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
> > Hi,
> >
> > In the last years we had few discussions on "simplifying" QEMU (system
> > emulation / virtualization), in particular for the "management layer".
> >
> > Some of us are
On Tue, 13 Dec 2022 at 14:14, Edgar E. Iglesias
wrote:
>
> On Tue, Dec 13, 2022 at 01:53:15PM +, Peter Maydell wrote:
> > On Tue, 13 Dec 2022 at 12:52, Philippe Mathieu-Daudé
> > wrote:
> > >
> > > This partly revert commit d48751ed4f ("xilinx-ethlite:
> > > Simplify byteswapping to/from bra
On Tue, Dec 13, 2022 at 09:17:40AM -0500, Stefan Hajnoczi wrote:
> On Tue, 13 Dec 2022 at 09:08, Philippe Mathieu-Daudé
> wrote:
> >
> > On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
> > > Hi,
> > >
> > > In the last years we had few discussions on "simplifying" QEMU (system
> > > emulation /
On 13/12/2022, 15:17, "Stefan Hajnoczi" wrote:
WARNING: This email originated from outside of Qualcomm. Please be wary of any
links or attachments, and do not enable macros.
On Tue, 13 Dec 2022 at 09:08, Philippe Mathieu-Daudé wrote:
>
> On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
> > H
On Tue, 13 Dec 2022 at 14:17, Stefan Hajnoczi wrote:
>
> On Tue, 13 Dec 2022 at 09:08, Philippe Mathieu-Daudé
> wrote:
> >
> > On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
> > > The call will be Tuesday, December 13 at 3pm CET on this Bluejeans link:
> > > http://bluejeans.com/quintela
> > W
On Tue, Dec 13, 2022 at 02:18:42PM +, Peter Maydell wrote:
> On Tue, 13 Dec 2022 at 14:14, Edgar E. Iglesias
> wrote:
> >
> > On Tue, Dec 13, 2022 at 01:53:15PM +, Peter Maydell wrote:
> > > On Tue, 13 Dec 2022 at 12:52, Philippe Mathieu-Daudé
> > > wrote:
> > > >
> > > > This partly rev
Hi all,
Does qemu-system-riscv64 have any plugin or tools that can support target
program function trace feature?
It seems there is no such feature under
link:https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/tcg-plugins.rst
For example, we can use libexeclog.so plugin to tra
hi,
the "5" key of my keyboard doesn't work in my guest machine (ArchLinux)
when I start qemu with the "-display sdl" option (I realized it when I
wanted to enter the network address 192.168.1.254).
the "5" key is OK if I switch to a terminal opened in the host machine.
I did not test the whole ke
On Mon, Dec 05, 2022 at 04:49:43PM +0800, Longpeng(Mike) wrote:
From: Longpeng
Signed-off-by: Longpeng
---
.../devices/vhost-vdpa-generic-device.rst | 66 +++
1 file changed, 66 insertions(+)
create mode 100644 docs/system/devices/vhost-vdpa-generic-device.rst
diff --git a/
On Tue, 13 Dec 2022 15:08:53 +0100
Philippe Mathieu-Daudé wrote:
> On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
> > Hi,
> >
> > In the last years we had few discussions on "simplifying" QEMU (system
> > emulation / virtualization), in particular for the "management layer".
> >
> > Some of
On 12/13/22 15:17, Stefan Hajnoczi wrote:
On Tue, 13 Dec 2022 at 09:08, Philippe Mathieu-Daudé wrote:
On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
Hi,
In the last years we had few discussions on "simplifying" QEMU (system
emulation / virtualization), in particular for the "management lay
Hi
On Tue, Dec 13, 2022 at 6:44 PM Cédric Le Goater wrote:
> On 12/13/22 15:17, Stefan Hajnoczi wrote:
> > On Tue, 13 Dec 2022 at 09:08, Philippe Mathieu-Daudé
> wrote:
> >>
> >> On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
> >>> Hi,
> >>>
> >>> In the last years we had few discussions on "
Philippe Mathieu-Daudé wrote:
> On 12/12/22 00:41, Philippe Mathieu-Daudé wrote:
>> Hi,
>> In the last years we had few discussions on "simplifying" QEMU
>> (system emulation / virtualization), in particular for the
>> "management layer".
>> Some of us are interested in having QEMU able to dynamic
Am 13.12.22 um 14:50 schrieb Christian Borntraeger:
Am 12.12.22 um 11:01 schrieb Pierre Morel:
On 12/9/22 15:45, Cédric Le Goater wrote:
On 12/8/22 10:44, Pierre Morel wrote:
Hi,
Implementation discussions
==
CPU models
--
Since the S390_FEAT_CONFIGURA
According to GLib changelog [1], since version 2.73.2 GLib is using
libpcre2 instead of libpcre. As a result, qemu-ga MSI installation
fails due to missing DLL when linked with the newer GLib.
This commit makes wixl to put the right libpcre version into the MSI
bundle: either libpcre-1.dll or lib
On 11/9/22 00:13, John Johnson wrote:
Add per-region FD to support mmap() of remote device regions
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
---
hw/vfio/common.c | 32 ---
hw/vfio/user-protocol.h | 1
On 12/12/22 22:55, Guenter Roeck wrote:
Do you plan to send a formal patch, or do you want me to do it ?
I can send a patch.
r~
On Tue, 13 Dec 2022 at 14:23, Edgar E. Iglesias
wrote:
>
> On Tue, Dec 13, 2022 at 02:18:42PM +, Peter Maydell wrote:
> > On Tue, 13 Dec 2022 at 14:14, Edgar E. Iglesias
> > wrote:
> > >
> > > On Tue, Dec 13, 2022 at 01:53:15PM +, Peter Maydell wrote:
> > > > On Tue, 13 Dec 2022 at 12:52,
On Tue, 2022-12-13 at 16:12 +0100, Christian Borntraeger wrote:
>
> Am 13.12.22 um 14:50 schrieb Christian Borntraeger:
> >
> >
> > Am 12.12.22 um 11:01 schrieb Pierre Morel:
> > >
> > >
> > > On 12/9/22 15:45, Cédric Le Goater wrote:
> > > > On 12/8/22 10:44, Pierre Morel wrote:
> > > > > Hi,
在 2022/12/13 22:35, Stefano Garzarella 写道:
On Mon, Dec 05, 2022 at 04:49:43PM +0800, Longpeng(Mike) wrote:
From: Longpeng
Signed-off-by: Longpeng
---
.../devices/vhost-vdpa-generic-device.rst | 66 +++
1 file changed, 66 insertions(+)
create mode 100644 docs/system/devic
On 12/13/22 01:30, Philippe Mathieu-Daudé wrote:
On 13/12/22 01:14, Richard Henderson wrote:
On 12/12/22 17:05, Philippe Mathieu-Daudé wrote:
The device endianness doesn't change during runtime.
What are you talking about? Of course it does.
The host CPU certainly does, but the virtio devi
On Tue, Dec 13, 2022 at 03:22:54PM +, Peter Maydell wrote:
> On Tue, 13 Dec 2022 at 14:23, Edgar E. Iglesias
> wrote:
> >
> > On Tue, Dec 13, 2022 at 02:18:42PM +, Peter Maydell wrote:
> > > On Tue, 13 Dec 2022 at 14:14, Edgar E. Iglesias
> > > wrote:
> > > >
> > > > On Tue, Dec 13, 2022
On Tue, Dec 13, 2022 at 11:37:35PM +0800, Longpeng (Mike, Cloud Infrastructure
Service Product Dept.) wrote:
在 2022/12/13 22:35, Stefano Garzarella 写道:
On Mon, Dec 05, 2022 at 04:49:43PM +0800, Longpeng(Mike) wrote:
From: Longpeng
Signed-off-by: Longpeng
---
.../devices/vhost-vdpa-generic
This quick test boots TF-A on the SBSA-ref machine up to the
EDK2 banner.
It was helpful to catch an issue with Secure PTW fixed in
commit cead7fa4c0 ("target/arm: Two fixes for secure ptw").
Prebuilt flash volumes are included, with the build recipes
to reproduce.
Example of execution:
$ avo
(BTW, really happy that we use another approach for next time - we only used it
because we didn’t have another quick choice when the meeting didn’t open….)
Cheers
Mark
On 13/12/2022, 15:52, "Marc-André Lureau" wrote:
WARNING: This email originated from outside of Qualcomm. Please be wary of
On Mon, Dec 12, 2022 at 12:38 PM Hanna Reitz wrote:
>
> On 28.11.22 15:15, Nir Soffer wrote:
> > Extend the test finder to find tests with format (*.out.qcow2) or cache
> > specific (*.out.nocache) out file. This worked before only for the
> > numbered tests.
> > ---
> > tests/qemu-iotests/findt
On 12/13/22 06:52, Philippe Mathieu-Daudé wrote:
Assuming the developers of commits 2c50e26efd ("powerpc: Add
a virtex5 ml507 refdesign board") and 4b387f9ee1 ("ppc: Add
aCube Sam460ex board") were testing on a little-endian setup,
they meant to use const_le32() instead of tswap32() here,
since t
Add two missing mmap flags.
Signed-off-by: Helge Deller
diff --git a/linux-user/strace.c b/linux-user/strace.c
index 8fa5c1ec3d..3ea91084fb 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -1089,6 +1089,8 @@ UNUSED static struct flags mmap_flags[] = {
#ifdef TARGET_MAP_UNINITIALIZE
The sparc, hppa and m68k architectures provide an own output for the
emulated /proc/cpuinfo file.
Some userspace applications count (even if that's not the recommended
way) the number of lines which start with "processor:" and assume that
this number then reflects the number of online CPUs. Since
On 13/12/22 17:00, Richard Henderson wrote:
On 12/13/22 06:52, Philippe Mathieu-Daudé wrote:
Assuming the developers of commits 2c50e26efd ("powerpc: Add
a virtex5 ml507 refdesign board") and 4b387f9ee1 ("ppc: Add
aCube Sam460ex board") were testing on a little-endian setup,
they meant to use co
On 11/9/22 00:13, John Johnson wrote:
PCI BARs read from remote device
PCI config reads/writes sent to remote server
Signed-off-by: Elena Ufimtseva
Signed-off-by: John G Johnson
Signed-off-by: Jagannathan Raman
Reviewed-by: Cédric Le Goater
Thanks,
C.
---
hw/vfio/pci.c | 277 ++
1 - 100 of 211 matches
Mail list logo
