On 19/04/2021 21:58, Philippe Mathieu-Daudé wrote:
Hi Mark,
On 4/19/21 10:13 PM, Mark Cave-Ayland wrote:
On 17/04/2021 15:02, Philippe Mathieu-Daudé wrote:
Since commit 2cdfcf272d ("memory: assign MemoryRegionOps to all
regions"), all newly created regions are assigned with
unassigned_mem_op
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
On 20/04/2021 04:35, Igor Druzhinin wrote:
When we're replacing the existing mapping there is possibility of a race
on memory map with other threads doing mmap operations - the address being
unmapped/re-mapped could be occupied by another thread in between.
Linux mmap man page recommends keeping
Try to open the udmabuf dev node for the first time or return the
fd if the device was previously opened.
Based-on-patch-by: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
include/ui/console.h | 3 +++
ui/meson.build | 1 +
ui/udmabuf.c | 40 +++
Store the meta-data associated with a FB in a new object
(struct virtio_gpu_framebuffer) and pass the object to set_scanout.
Also move code in set_scanout into a do_set_scanout function.
This will be helpful when adding set_scanout_blob API.
Based-on-patch-by: Gerd Hoffmann
Signed-off-by: Vivek K
Add the property bit, configuration flag and other relevant
macros and definitions associated with this feature.
Based-on-patch-by: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
hw/display/virtio-gpu-base.c | 3 +++
hw/display/virtio-gpu.c| 14 ++
include/hw/virtio/vir
Move finding the resource and validating its backing storage into one
function.
Based-on-patch-by: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
hw/display/virtio-gpu.c | 66 +
1 file changed, 47 insertions(+), 19 deletions(-)
diff --git a/hw/display/
Enabling this feature would eliminate data copies from the resource
object in the Guest to the shadow resource in Qemu. This patch series
however adds support only for Blobs of type
VIRTIO_GPU_BLOB_MEM_GUEST with property VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE.
Most of the patches in this series are a
Add helper functions to create a dmabuf for a resource and mmap it.
To be able to create a dmabuf using the udmabuf driver, Qemu needs
to be lauched with the memfd memory backend like this:
qemu-system-x86_64 -m 8192m -object memory-backend-memfd,id=mem1,size=8192M
-machine memory-backend=mem1
Ba
This new function to get the drm_format associated with a pixman
format will be useful while creating a dmabuf.
Based-on-patch-by: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
include/ui/qemu-pixman.h | 1 +
ui/qemu-pixman.c | 35 ---
2 files changed
Instead of passing the attach_backing object to extract nr_entries
and offset, explicitly pass these as arguments to this function.
This will be helpful when adding create_blob API.
Signed-off-by: Vivek Kasireddy
---
hw/display/virtio-gpu-3d.c | 3 ++-
hw/display/virtio-gpu.c| 22 ++
Creating a small helper function for updating the scanout
will be useful in the next patch where this needs to be
done early in do_set_scanout before returning.
Signed-off-by: Vivek Kasireddy
---
hw/display/virtio-gpu.c | 35 +++
1 file changed, 23 insertions(+),
This API allows Qemu to register the blob allocated by the Guest
as a new resource and map its backing storage.
Based-on-patch-by: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
hw/display/trace-events | 1 +
hw/display/virtio-gpu-udmabuf.c | 9 +++-
hw/display/virtio-gpu.
These helpers can be useful for creating dmabuf objects from blobs
and submitting them to the UI.
Signed-off-by: Vivek Kasireddy
---
hw/display/virtio-gpu-udmabuf.c | 87 +
include/hw/virtio/virtio-gpu.h | 15 ++
2 files changed, 102 insertions(+)
diff --git
This API allows Qemu to set the blob allocated by the Guest as
the scanout buffer. If Opengl support is available, then the
scanout buffer would be submitted as a dmabuf to the UI; if not,
a pixman image is created from the scanout buffer and is
submitted to the UI via the display surface.
Based-o
If a blob is available for the cursor, copy the data from the blob.
Based-on-patch-by: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
hw/display/virtio-gpu.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gp
On Apr 20 07:53, Thomas Huth wrote:
On 19/04/2021 21.27, Klaus Jensen wrote:
From: Klaus Jensen
Get rid of the (reserved) double underscore use.
Cc: Philippe Mathieu-Daudé
Cc: Thomas Huth
Signed-off-by: Klaus Jensen
---
hw/block/nvme.c | 16 ++--
1 file changed, 10 insertions(
On 2021/4/20 下午2:26, Alistair Francis wrote:
On Tue, Apr 20, 2021 at 11:45 AM LIU Zhiwei wrote:
On 2021/4/20 上午7:30, Alistair Francis wrote:
On Fri, Apr 9, 2021 at 5:56 PM LIU Zhiwei wrote:
This patch set gives an implementation of "RISC-V Core-Local Interrupt
Controller(CLIC) Version 0.9
On 19/04/2021 22:11, Philippe Mathieu-Daudé wrote:
My patch might not be the proper fix, but we need to figure out how
to avoid others to hit the same problem, as it is very hard to debug.
At least an assertion and a comment.
Something like:
-- >8 --
diff --git a/softmmu/memory.c b/softmmu/m
Upstream commit:
https://git.qemu.org/?p=qemu.git;a=commit;h=3791642c8d60029adf9b00bcb4e34d7d8a1aea4d
** Changed in: qemu
Status: New => 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/
The IBEX documentation [1] specifies the reset vector to be "the most
significant 3 bytes of the boot address and the reset value (0x80) as
the least significant byte".
[1]
https://github.com/lowRISC/ibex/blob/master/doc/03_reference/exception_interrupts.rst
Signed-off-by: Alexander Wagner
Revi
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
** Changed in: qemu
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1811888
Title:
Qemu refuses to multiboot Elf64 kernels
Status in QEMU:
New
Bug description
On Tue, Apr 20, 2021 at 07:19:06AM +0200, Markus Armbruster wrote:
> Result @blocked is true when and only when result @blocked-reasons is
> present. It's always non-empty when present. @blocked is redundant.
> It was introduced in commit 3af8554bd0 "migration: Add blocker
> information", and has
On Mon, Apr 19, 2021 at 08:06:23PM +0100, Dr. David Alan Gilbert wrote:
> * Jing-Wei Su (jwsu1...@gmail.com) wrote:
> > Hello experts,
> >
> >
> > I have a network topology like this diagram.
> >
> > When start live migration moving a VM from Host A to B,
> >
> > the migration process uses eith
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
This might also be a duplicate of bug
https://bugs.launchpad.net/qemu/+bug/1813307
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1808563
Title:
Listing the contents of / lists QEMU_LD_PREFIX instea
QEMU, like most open source projects, relies on contributors who have
motivation, skills and available time to work on implementing particular
features. They naturally tend to focus on features that result in the
greatest benefit to their own use cases. Thus simply declaring that an
open source pro
sorry for the previous post, posted the wrong text into this bug :-(
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1818122
Title:
QEMU 3.1 makes libxslt to crash on ppc64
Status in QEMU:
Incompl
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
I meant to say:
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then p
John, did you find some spare time to work on those patches that you've
mentioned? I.e. has this been addressed already?
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bug
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
On Tue, Apr 20, 2021 at 07:19:07AM +0200, Markus Armbruster wrote:
> Result @blocked is true when and only when result @blocked-reasons is
> present. It's always non-empty when present. @blocked is redundant.
> It was introduced in commit 3af8554bd0 "migration: Add blocker
> information", and has
Looking through old bug tickets... can you still reproduce this issue
with the latest version of QEMU? Or could we close this ticket nowadays?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1819908
Ti
The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the
On Tue, Apr 20, 2021 at 04:35:02AM +0100, Igor Druzhinin wrote:
> When we're replacing the existing mapping there is possibility of a race
> on memory map with other threads doing mmap operations - the address being
> unmapped/re-mapped could be occupied by another thread in between.
>
> Linux mma
I just checked it out with QEMU 5.2.0 and it seems that the bug has been
fixed.
** Changed in: qemu
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1818122
Ti
On Mon, 19 Apr 2021 at 21:36, Richard Henderson
wrote:
>
> Using cpu_abort takes care of things like unregistering a
> SIGABRT handler for user-only.
I would find this argument more persuasive if we didn't have a
ton of other places where we call abort() or assert() or
g_assert_not_reached(). Eit
On 4/20/21 9:00 AM, Mark Cave-Ayland wrote:
> On 19/04/2021 21:58, Philippe Mathieu-Daudé wrote:
>
>> Hi Mark,
>>
>> On 4/19/21 10:13 PM, Mark Cave-Ayland wrote:
>>> On 17/04/2021 15:02, Philippe Mathieu-Daudé wrote:
>>>
Since commit 2cdfcf272d ("memory: assign MemoryRegionOps to all
reg
On 20/04/2021 13:14, David Gibson wrote:
Overall, looking good. I'm pretty much happy to take it into 6.1. I
do have quite a few comments below, but they're basically all just
polish.
On Wed, Mar 31, 2021 at 01:53:08PM +1100, Alexey Kardashevskiy wrote:
The PAPR platform which describes a
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, Apr 20, 2021 at 07:19:06AM +0200, Markus Armbruster wrote:
> > Result @blocked is true when and only when result @blocked-reasons is
> > present. It's always non-empty when present. @blocked is redundant.
> > It was introduced in commit
On 4/19/21 4:26 PM, Peter Maydell wrote:
> On Fri, 9 Apr 2021 at 07:24, Philippe Mathieu-Daudé wrote:
>>
>> To enforce correct API usage, restrict the clock creation to
>> hw/core/. The only possible ways to create a clock are:
>>
>> - Constant clock at the board level
>> Using machine_create_co
This is still a bug, and still blocked on the kernel providing APIs to QEMU to
request 32-bit directory entries. Linus Walleij proposed a kernel patch to add
a suitable fcntl flag but as far as I'm aware it didn't get in so far:
https://lore.kernel.org/qemu-devel/20201117233928.255671-1-linus.w
Code inspection shows we still don't handle /proc/self/task.
** Changed in: qemu
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1808565
Title:
Reading /proc/
Claudio Fontana writes:
> On 4/19/21 12:29 PM, Thomas Huth wrote:
>> On 19/04/2021 12.24, Claudio Fontana wrote:
>>> On 4/19/21 12:22 PM, Thomas Huth wrote:
On 16/04/2021 18.27, Claudio Fontana wrote:
> Skip the test_device_intro_concrete for now for ARM KVM-only build,
> as on ARM
Virtual Machines can exploit bus locks to degrade the performance of
system. To address this kind of performance DOS attack, bus lock VM exit
is introduced in KVM and it will report the bus locks detected in guest,
which can help userspace to enforce throttling policies.
The availability of bus lo
Thanks for looking into this patch David,
David Gibson writes:
> On Thu, Apr 15, 2021 at 01:23:43PM +0530, Vaibhav Jain wrote:
>> Add support for H_SCM_PERFORMANCE_STATS described at [1] for
>> spapr nvdimms. This enables guest to fetch performance stats[2] like
>> expected life of an nvdimm ('M
On 20/04/2021 09:53, Roger Pau Monné wrote:
On Tue, Apr 20, 2021 at 04:35:02AM +0100, Igor Druzhinin wrote:
When we're replacing the existing mapping there is possibility of a race
on memory map with other threads doing mmap operations - the address being
unmapped/re-mapped could be occupied by
On 20/04/2021 04:39, no-re...@patchew.org wrote:
Patchew URL:
https://patchew.org/QEMU/1618889702-13104-1-git-send-email-igor.druzhi...@citrix.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 1618889702-13104-1-gi
On 4/13/21 11:14 AM, David Hildenbrand wrote:
> Let's pass in ram flags just like we do with qemu_ram_alloc_from_file(),
> to clean up and prepare for more flags.
>
> Simplify the documentation of passed ram flags: Looking at our
> documentation of RAM_SHARED and RAM_PMEM is sufficient, no need to
Claudio Fontana writes:
> Signed-off-by: Claudio Fontana
> Reviewed-by: Richard Henderson
Reviewed-by: Alex Bennée
--
Alex Bennée
On Mon, 19 Apr 2021 20:38:05 +0100
Mark Cave-Ayland wrote:
> On 19/04/2021 18:02, Cornelia Huck wrote:
>
> >> That patch seems to be our best candidate so far, but the intermittent
> >> nature of the failures make it hard to pin down... I don't see anything
> >> obviously wrong with the patch, m
This serie of patches continues Paolo's series on making the
block layer thread safe. Add a CoMutex lock for both tasks and
calls list present in block/block-copy.c
Signed-off-by: Emanuele Giuseppe Esposito
Emanuele Giuseppe Esposito (3):
block-copy: improve documentation for BlockCopyTask typ
Because the list of tasks is only modified by coroutine
functions, add a CoMutex in order to protect the list of tasks.
Signed-off-by: Emanuele Giuseppe Esposito
---
block/block-copy.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/block/block-copy.c
Use the same tasks_lock, since the calls list is just used
for debug purposes.
Signed-off-by: Emanuele Giuseppe Esposito
---
block/block-copy.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/block/block-copy.c b/block/block-copy.c
index e785ac57e0..555f5fb747 100644
-
When adding this file and its new content in commit 3f7a927847a
("target/mips: LSA/DLSA R6 decodetree helpers") I did 2 mistakes:
1: Listed authors who haven't been involved in its development,
2: Used an incorrect GNU GPLv2 license text (using 'and' instead
of 'or').
Instead of correcting the
As done in BlockCopyCallState, categorize BlockCopyTask
in IN, State and OUT fields. This is just to understand
which field has to be protected with a lock.
Also add coroutine_fn attribute to block_copy_task_create,
because it is only usedn block_copy_dirty_clusters, a coroutine
function itself.
On Tue, 20 Apr 2021 at 11:06, Philippe Mathieu-Daudé wrote:
>
> When adding this file and its new content in commit 3f7a927847a
> ("target/mips: LSA/DLSA R6 decodetree helpers") I did 2 mistakes:
>
> 1: Listed authors who haven't been involved in its development,
> 2: Used an incorrect GNU GPLv2 l
Hi David,
On 4/20/21 11:52 AM, Philippe Mathieu-Daudé wrote:
> On 4/13/21 11:14 AM, David Hildenbrand wrote:
>> Let's pass in ram flags just like we do with qemu_ram_alloc_from_file(),
>> to clean up and prepare for more flags.
>>
>> Simplify the documentation of passed ram flags: Looking at our
>
Hi David,
On 4/13/21 11:14 AM, David Hildenbrand wrote:
> Let's forward ram_flags instead, renaming
> memory_region_init_ram_shared_nomigrate() into
> memory_region_init_ram_flags_nomigrate(). Forward flags to
> qemu_ram_alloc() and qemu_ram_alloc_internal().
>
> Reviewed-by: Peter Xu
> Signed-o
On Thu, Mar 25, 2021 at 04:33:15PM +, Peter Maydell wrote:
> Currently the gpex PCI controller implements no special behaviour for
> guest accesses to areas of the PIO and MMIO where it has not mapped
> any PCI devices, which means that for Arm you end up with a CPU
> exception due to a data ab
On 4/13/21 11:14 AM, David Hildenbrand wrote:
> Let's introduce RAM_NORESERVE, allowing mmap'ing with MAP_NORESERVE. The
> new flag has the following semantics:
>
> "
> RAM is mmap-ed with MAP_NORESERVE. When set, reserving swap space (or huge
> pages if applicable) is skipped: will bail out if no
On Tue, Apr 20, 2021 at 10:45:03AM +0100, Igor Druzhinin wrote:
> On 20/04/2021 09:53, Roger Pau Monné wrote:
> > On Tue, Apr 20, 2021 at 04:35:02AM +0100, Igor Druzhinin wrote:
> > > When we're replacing the existing mapping there is possibility of a race
> > > on memory map with other threads doi
On 4/13/21 11:14 AM, David Hildenbrand wrote:
> Let's include the property, which can be helpful when debugging,
> for example, to spot misuse of MAP_PRIVATE which can result in some ugly
> corner cases (e.g., double-memory consumption on shmem).
>
> Use the same description we also use for descri
On 4/13/21 11:14 AM, David Hildenbrand wrote:
> We return information on the currently configured memory backends and
> don't configure them, so decribe what the currently set properties
> express.
>
> Suggested-by: Markus Armbruster
> Cc: Eric Blake
> Cc: Markus Armbruster
> Cc: Igor Mammedov
On 20.04.21 12:20, Philippe Mathieu-Daudé wrote:
Hi David,
On 4/13/21 11:14 AM, David Hildenbrand wrote:
Let's forward ram_flags instead, renaming
memory_region_init_ram_shared_nomigrate() into
memory_region_init_ram_flags_nomigrate(). Forward flags to
qemu_ram_alloc() and qemu_ram_alloc_intern
On Mon, 19 Apr 2021 at 21:24, Richard Henderson
wrote:
>
> Based-on: 20210416183106.1516563-1-richard.hender...@linaro.org
> ("[PATCH v5 for-6.1 0/9] target/arm mte fixes")
>
> Changes for v5:
> * Address review issues.
> * Use cpu_abort in assert_hflags_rebuild_correctly
>
> The only patch la
Claudio Fontana writes:
> before exporting some functionality from helper.c into a new module,
> fix the comment style of those functions.
>
> Signed-off-by: Claudio Fontana
> Reviewed-by: Richard Henderson
Reviewed-by: Alex Bennée
--
Alex Bennée
Claudio Fontana writes:
> We do not move psci.c to tcg/ because we expect other
> hypervisors to use it (waiting for HVF enablement).
>
> Signed-off-by: Claudio Fontana
> Cc: Alexander Graf
> Reviewed-by: Richard Henderson
Reviewed-by: Alex Bennée
--
Alex Bennée
Claudio Fontana writes:
> in preparation of the creation of a new cpregs module,
> fix the style for the to-be-exported code.
>
> Signed-off-by: Claudio Fontana
> Reviewed-by: Richard Henderson
Reviewed-by: Alex Bennée
--
Alex Bennée
On 20.04.21 12:18, Philippe Mathieu-Daudé wrote:
Hi David,
On 4/20/21 11:52 AM, Philippe Mathieu-Daudé wrote:
On 4/13/21 11:14 AM, David Hildenbrand wrote:
Let's pass in ram flags just like we do with qemu_ram_alloc_from_file(),
to clean up and prepare for more flags.
Simplify the documentati
now that we protect all calls to the tcg-specific functions
with if (tcg_enabled()), we do not need the TCG stub anymore.
Signed-off-by: Claudio Fontana
---
target/s390x/tcg-stub.c | 30 --
target/s390x/meson.build | 2 +-
2 files changed, 1 insertion(+), 31 deletio
this will allow in later patches to remove unneeded stubs
in target/s390x.
Signed-off-by: Claudio Fontana
---
hw/s390x/meson.build | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/s390x/meson.build b/hw/s390x/meson.build
index 327e9c93af..a4d355b4db 100644
--- a/hw/s390
Hi,
this is the next version of a cleanup series for s390x.
v1 -> v2: split more, stubs removal for KVM, kvm/ move, sysemu cpu models
* "hw/s390x: rename tod-qemu.c to tod-tcg.c"
- new patch (Cornelia)
* "hw/s390x: tod: make explicit checks for accelerators when initializing"
- now error ou
replace general "else" with specific checks for each possible accelerator.
Handle qtest as a NOP,
and error out for an unknown accelerator used in combination with tod.
Signed-off-by: Claudio Fontana
---
hw/s390x/tod.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/
Signed-off-by: Claudio Fontana
---
target/s390x/cpu-dump.c | 131 +++
target/s390x/helper.c| 107
target/s390x/meson.build | 1 +
3 files changed, 132 insertions(+), 107 deletions(-)
create mode 100644 target/s390x/cpu-d
this will allow to remove the kvm stubs.
Signed-off-by: Claudio Fontana
---
target/s390x/diag.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/s390x/diag.c b/target/s390x/diag.c
index 86b7032b5b..311e22b4ea 100644
--- a/target/s390x/diag.c
+++ b/target/s390x/diag.c
we stop short of renaming the actual qom object though,
so type remains TYPE_QEMU_S390_TOD, ie "s390-tod-qemu".
Signed-off-by: Claudio Fontana
---
hw/s390x/{tod-qemu.c => tod-tcg.c} | 0
hw/s390x/meson.build | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename hw/s390x/{t
move everything related to translate, as well as HELPER code in tcg/
mmu_helper.c stays put for now, as it contains both TCG and KVM code.
The internal.h file is renamed to s390x-internal.h, because of the
risk of collision with other files with the same name.
Signed-off-by: Claudio Fontana
---
Signed-off-by: Claudio Fontana
---
target/s390x/{ => kvm}/kvm_s390x.h | 0
hw/intc/s390_flic_kvm.c| 2 +-
hw/s390x/s390-stattrib-kvm.c | 2 +-
hw/s390x/tod-kvm.c | 2 +-
hw/vfio/ap.c | 2 +-
target/s390x/cpu-sysemu.c | 2 +-
t
Signed-off-by: Claudio Fontana
---
target/s390x/s390x-internal.h | 6 +
target/s390x/cpu-sysemu.c | 304 ++
target/s390x/cpu.c| 283 ++-
target/s390x/meson.build | 1 +
target/s390x/trace-events | 2 +-
5 f
Now that we have moved cpu-dump functionality out of helper.c,
we can make the module sysemu-only.
Signed-off-by: Claudio Fontana
---
target/s390x/helper.c| 4
target/s390x/meson.build | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/target/s390x/helper.c b/target/s
After the reshuffling, update MAINTAINERS accordingly.
Make use of the new directories:
target/s390x/kvm/
target/s390x/tcg/
Signed-off-by: Claudio Fontana
---
MAINTAINERS | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7de873c9f5..3d73
also create a tiny _user.c with just the (at least for now),
empty implementation of apply_cpu_model.
Signed-off-by: Claudio Fontana
---
target/s390x/s390x-internal.h| 2 +
target/s390x/cpu_models.c| 417 +-
target/s390x/cpu_models_sysemu.c | 426 +++
all function calls are protected by kvm_enabled(),
so we should not need the stubs.
Signed-off-by: Claudio Fontana
---
target/s390x/kvm-stub.c | 126 ---
target/s390x/meson.build | 2 +-
2 files changed, 1 insertion(+), 127 deletions(-)
delete mode 100644
On 4/13/21 11:14 AM, David Hildenbrand wrote:
> Let's print the new property.
>
> Reviewed-by: Dr. David Alan Gilbert
> Cc: Markus Armbruster
> Cc: Eric Blake
> Cc: Igor Mammedov
> Signed-off-by: David Hildenbrand
> ---
> hw/core/machine-hmp-cmds.c | 2 ++
> 1 file changed, 2 insertions(+)
On 4/13/21 11:14 AM, David Hildenbrand wrote:
> Let's include the new property.
>
> Cc: Eric Blake
> Cc: Markus Armbruster
> Cc: Igor Mammedov
> Signed-off-by: David Hildenbrand
> ---
> hw/core/machine-qmp-cmds.c | 1 +
> qapi/machine.json | 4
> 2 files changed, 5 insertions(+)
On 4/20/21 12:27 PM, David Hildenbrand wrote:
> On 20.04.21 12:20, Philippe Mathieu-Daudé wrote:
>> Hi David,
>>
>> On 4/13/21 11:14 AM, David Hildenbrand wrote:
>>> Let's forward ram_flags instead, renaming
>>> memory_region_init_ram_shared_nomigrate() into
>>> memory_region_init_ram_flags_nomigra
1 - 100 of 276 matches
Mail list logo
