l need to be added that is common in the initialization of hvf and kvm.
I am not sure what could be a better name for the function
host_cpu_instance_init(),
but maybe its name would not confuse so much anymore if it is contained in a
file that specifically includes this common code,
excluding all &quo
line, and that gets
me to:
2972153@1743002351.233130:vdagent_open
2972192@1743002362.649762:vdagent_close
2972192@1743002362.649771:vdagent_disconnect
Apparently the vdagent connection is closed after 11 seconds, but I have no
idea why..
Thanks for any suggestions,
Claudio
--
Claudio Fontana
Engineering Manager Virtualization, SUSE Labs Core
SUSE Software Solutions Italy Srl
On Mon, 30 Sep 2024 15:14:52 +0200
David Hildenbrand wrote:
> On 30.09.24 13:37, Claudio Imbrenda wrote:
> > On Mon, 30 Sep 2024 13:15:52 +0200
> > Christian Borntraeger wrote:
> >
> >> Am 24.09.24 um 22:17 schrieb David Hildenbrand:
> >>> On 24.
_PROTECTED_ASYNC_DISABLE)) {
> >>> return false;
> >>> }
> >>
> >> If I understood the kernel code right, the decision is made wrt
> >> the size of the gmap address space, which is the same as the
> >> limit set for the
ping, adding Richard.
We will need to include this downstream because of the breakage its lack causes.
It is already reviewed by me, but some TCG maintainer indicating it will be
included in some queue would help,
Thanks,
Claudio
On 9/18/24 17:11, Claudio Fontana wrote:
> Adding Ilya
Adding Ilya FYI.
Ciao,
Claudio
On 9/11/24 18:19, Claudio Fontana wrote:
> On 9/11/24 16:16, Fabiano Rosas wrote:
>> The XT check for the lxvx/stxvx instructions is currently
>> inverted. This was introduced during the move to decodetree.
>>
>> From the ISA:
&g
On 9/9/24 12:07, Claudio Fontana wrote:
> On 9/9/24 11:54, Daniel Henrique Barboza wrote:
>>
>>
>> On 9/9/24 12:17 AM, Andrew.Yuan wrote:
>>> The code 'ops = ACCEL_OPS_CLASS(module_object_class_by_name(ops_name));' is
>>> unnecessary;
>
tx, arg_X *a, bool store, bool paired)
> {
> - if (paired || a->rt >= 32) {
> +if (paired || a->rt < 32) {
> REQUIRE_VSX(ctx);
> } else {
> REQUIRE_VECTOR(ctx);
Reviewed-by: Claudio Fontana
o guess (first time looking at this code), ACCEL_OPS_CLASS() is creating the
> class
> type QOM functions that the the second module_object_class_by_name() relies
> on to
> catch the module load error the commit is trying to address.
>
> I'm CCing Claudio to get a better i
Reviewed-by: Claudio Fontana
On 8/12/24 10:57, Alexander Ivanov wrote:
> Move local_err initialization inside the loop in the module_load_qom_all()
> function. This change ensures that the error variable is reset to NULL for
> each iteration of the loop. This prevents triggering ass
(module_load("", modinfo->name, &local_err) < 0) {
> error_report_err(local_err);
> +local_err = NULL;
> }
> }
> module_loaded_qom_all = true;
Reviewed-by: Claudio Fontana
gltm, thanks!
Reviewed-by: Claudio Fontana
On 8/9/24 07:10, Ani Sinha wrote:
> Refactoring the core logic around KVM_CREATE_VM into its own separate function
> so that it can be called from other functions in subsequent patches. There is
> no functional change in this patch.
>
Hello,
as a suggestion you could adjust the names of the functions to match the
existing pattern in this module.
It is modulename_method ie kvm_* , so:
On 8/8/24 13:38, Ani Sinha wrote:
> Refactoring the core logic around KVM_CREATE_VM into its own separate function
> so that it can be called f
a
partial match ...
Add a check for this. While at it, fold a number of explicitly handled
special cases into the generic logic.
Cc: qemu-sta...@nongnu.org
Reported-by: Claudio Fontana
Closes: https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg00633.htm
On 5/6/24 13:20, Thomas Huth wrote:
> The old "-runas" option has the disadvantage that it is not visible
> in the QAPI schema, so it is not available via the normal introspection
> mechanisms. We've recently introduced the "-run-with" option for exactly
> this purpose, which is meant to handle the
Thanks Philippe, I fear I am unable to really be uptodate,
but it's great to see all the cleanup you and others have done!
Ciao,
Claudio
On 3/19/24 16:48, Philippe Mathieu-Daudé wrote:
> (Forgot to Cc Claudio to keep him updated)
>
> On 19/3/24 16:42, Philippe Mathieu-Daud
fix, although in my view already fixing the
existing bad default would already be a big improvement in the meantime.
Thoughts?
Thanks,
Claudio
On 3/15/24 17:59, Nina Schoetterl-Glausch wrote:
> On Thu, 2024-03-14 at 22:37 +0100, Claudio Fontana wrote:
>> some users were confused by this message showing under TCG:
>>
>> Selected CPU generation is too new. Maximum supported model
>> in the configuration: &
est trying
different accel, QEMU and kernel versions.
Signed-off-by: Claudio Fontana
---
target/s390x/cpu_models.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 1a1c096122..8ed3bb6a27 100644
--
On 3/14/24 21:10, Claudio Fontana wrote:
> On 3/14/24 20:44, Nina Schoetterl-Glausch wrote:
>> On Thu, 2024-03-14 at 20:00 +0100, Claudio Fontana wrote:
>>> some users were confused by this message showing under TCG:
>>>
>>> Selected CPU generation is too new
On 3/14/24 20:44, Nina Schoetterl-Glausch wrote:
> On Thu, 2024-03-14 at 20:00 +0100, Claudio Fontana wrote:
>> some users were confused by this message showing under TCG:
>>
>> Selected CPU generation is too new. Maximum supported model
>> in the configuration: 'xy
eration is too new. Maximum supported model
in the accelerator 'tcg' configuration: 'xyz'
Signed-off-by: Claudio Fontana
---
target/s390x/cpu_models.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/target/s390x/cpu_models.c b/target/s390x
On 3/14/24 17:44, Nina Schoetterl-Glausch wrote:
> On Thu, 2024-03-14 at 16:54 +0100, Thomas Huth wrote:
>> On 14/03/2024 16.49, Claudio Fontana wrote:
>>> Hello Pierre, Ilya,
>>>
>>> I have a question on the s390x "topology" feature and examples.
>
-by: Claudio Fontana
---
docs/system/introduction.rst | 2 ++
docs/system/s390x/cpu-topology.rst | 14 --
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/docs/system/introduction.rst b/docs/system/introduction.rst
index 51ac132d6c..746707eb00 100644
--- a/docs
0,core-id=14 \
\
-device gen16b-s390x-cpu,core-id=4,dedicated=on,entitlement=high
"
We received questions about this, so I hope you can shed some light, maybe it
would be good to just update the web page to include -accel kvm or -enable-kvm
everywhere for clarity?
Thanks for your hel
ltifd 8 ch. |230812497551 14900 1862
>> + direct-io | 27475 1788025 46736 5842
>> ---
>
> Also surprised on direct-io too.. that is definitely something tremendous.
>
Awesome! Can't wait to have this available for our customers.
Ciao,
Claudio
Hello David,
It would seem to me that a lot of the calling code like qemu_prealloc_mem for
example
should be sysemu-only, not used for tools, or user mode either right?
And the thread_context.c itself should also be sysemu-only, correct?
Thanks,
Claudio
On 2/5/24 15:15, David Hildenbrand
ome conditional we could use to avoid the apparently
useless dependency to libnuma in the qemu-img binary?
Ciao,
Claudio
On 10/28/22 11:52, David Hildenbrand wrote:
> Let's make it easier to pin threads created via a ThreadContext to
> all host CPUs currently belonging to a give
On Fri, 12 Jan 2024 11:00:57 +0100
Thomas Huth wrote:
> It's been marked as deprecated since QEMU 8.1 (and was only available
> since QEMU 8.0 anyway), so it should be fine to remove this now.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Claudio Imbrenda
> ---
> do
n
*execution
with that fixed:
Reviewed-by: Claudio Imbrenda
> host key. However, if you still (accidentally) do it, you only get a
> very user-unfriendly error message that looks like this:
>
> qemu-system-s390x: KVM PV command 2 (KVM_PV_SET_SEC_PARMS) failed:
> header rc 108 rr
t's provide at least a somewhat nicer hint to the users so that they
> are able to figure out what might have gone wrong.
>
> Buglink: https://issues.redhat.com/browse/RHEL-18212
> Signed-off-by: Thomas Huth
Reviewed-by: Claudio Imbrenda
> ---
> target/s390x/kvm/p
On 11/30/23 18:51, Daniel P. Berrangé wrote:
> On Thu, Nov 30, 2023 at 05:54:26PM +0100, David Hildenbrand wrote:
>> On 30.11.23 17:01, Sean Christopherson wrote:
>>> On Thu, Nov 30, 2023, David Hildenbrand wrote:
On 30.11.23 08:32, Xiaoyao Li wrote:
> On 11/20/2023 5:26 PM, David Hildenbr
On 11/30/23 14:31, Philippe Mathieu-Daudé wrote:
> Hi Claudio,
>
> On 30/11/23 13:48, Claudio Fontana wrote:
>> Hi Philippe,
>>
>> took a quick look with
>>
>> grep -R can_do_io
>>
>> and this seems to be in include/hw/core/cpu.h as well as cpu-
?
This might help find problems of the field being used in the wrong context, by
virtue of getting an error when compiling with --disable-tcg for example.
Ciao,
Claudio
On 11/29/23 21:50, Philippe Mathieu-Daudé wrote:
> 'can_do_io' is specific to TCG. Having it set in non-TCG
> c
Reviewed-by: Claudio Fontana
On 11/10/23 18:08, Richard Henderson wrote:
> In cpu_exec_step_atomic, we did not set CF_LAST_IO, which can
> lead to a loop with cpu_io_recompile.
>
> But since 18a536f1f8 ("Always require can_do_io") we no longer need
> a flag to indicate
#x27;t handle a very high
> PCI space, then a workaround in the PCI code might make it more clear
> what is occurring.)
>
> Cheers,
> -Kevin
>
>
>>
>> Cc: Claudio Fontana
>> Signed-off-by: Gerd Hoffmann
Hi,
I thought about this, and I am not sure it&#
for the dump file.
>
> Let's add a cleanup function that tries to do a dump end. The dump
> completion data is discarded but there's no point in writing it to a
> file anyway if there's a possibility that other PV dump data is
> missing.
>
> Signed-off-by: Janosch Fr
On Tue, 7 Nov 2023 14:20:46 +
Janosch Frank wrote:
> dump_state_prepare() now sets the fucntion pointers to NULL so we only
> need to touch them if we're going to use them.
>
> Signed-off-by: Janosch Frank
I would merge this and the previous patch
> ---
> target/s390x/arch_dump.c | 4 --
rks, I tested with the 46 bit limit.
In terms of virt-install, I used the extra option:
--qemu-commandline='-cpu host,host-phys-bits-limit=46'
Charles maybe something to update the older os info definitions (for QEMU 8.2
and newer..?)
The idea is just that the toolstack could automatically correct for this for
older Linux guests, requiring a limit on the host-phys-bits.
Exactly how, I don't know what's best.
Thanks,
Claudio
On 11/7/23 11:35, Gerd Hoffmann wrote:
> Hi,
>
>> Trying to install a simple centos7 iso for testing as in:
>>
>> IMAGESDIR=/images
>> ISO=${IMAGESDIR}/CentOS-7-x86_64-Minimal-2009.iso
>
> Oh, you are running a software museum ;)
>
>> ===
On Fri, 20 Oct 2023 16:15:09 +0200
Eric Farman wrote:
> These are simple typos, since the directories don't exist but the
> files themselves do in hw/s390x/
>
> Fixes: 56e3483402 ("MAINTAINERS: split out s390x sections")
> Signed-off-by: Eric Farman
On 10/4/23 12:05, Philippe Mathieu-Daudé wrote:
> Hi,
>
> I'm getting a bunch of errors for 'optarg' declared in :
>
> NAME
> getopt – get option character from command line argument list
>
> LIBRARY
> Standard C Library (libc, -lc)
>
> SYNOPSIS
> #include
>
> extern c
pective.
We already have exposed "system" to the user as a way to mean this, as in:
./configure --enable-system
./configure --disable-system
and if everything is renamed from softmmu to system where it makes sense in the
code,
it's the best option for development as well in my view.
Thanks,
Claudio
On 10/3/23 16:04, Richard Henderson wrote:
> On 10/2/23 23:44, Philippe Mathieu-Daudé wrote:
>> On 15/9/23 21:00, Philippe Mathieu-Daudé wrote:
>>> - Add missing accel_cpu_unrealize()
>>> - Add AccelClass::[un]realize_cpu handlers
>>> - Use tcg_exec_[un]realizefn as AccelClass handlers
>>>
>>> Phil
Nice. I build-tested and make checked this as well,
Reviewed-by: Claudio Fontana
Tested-by: Claudio Fontana
On 10/3/23 14:30, Philippe Mathieu-Daudé wrote:
> Since v1:
> - Use 'target'/'common' in function names (Claudio)
> - Added Claudio R-b tags
-Daudé
Reviewed-by: Claudio Fontana
> ---
> accel/tcg/internal.h | 3 +++
> include/exec/cpu-all.h | 2 --
> accel/tcg/tcg-all.c| 2 ++
> cpu.c | 8
> 4 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/accel/tcg/internal
thieu-Daudé
Reviewed-by: Claudio Fontana
> ---
> include/exec/cpu-all.h | 2 +-
> accel/tcg/cpu-exec.c | 4 +++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
> index c2c62160c6..1e5c530ee1 100644
>
On 9/15/23 21:00, Philippe Mathieu-Daudé wrote:
> Currently accel_cpu_realize() only performs target-specific
> realization. Introduce the [un]realize_cpu fields in the
> base AccelClass to be able to perform target-agnostic
> [un]realization of vCPUs.
>
> Signed-off-by: Philippe Mathieu-Daudé
J
Reviewed-by: Claudio Fontana
On 9/15/23 21:00, Philippe Mathieu-Daudé wrote:
> We use the '*fn' suffix for handlers, this is a public method.
> Drop the suffix.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/qemu/accel.h | 4 ++--
> accel/acce
On 9/13/23 15:00, Claudio Fontana wrote:
> On 8/30/23 15:09, Claudio Fontana wrote:
>> On 8/22/23 15:25, Philippe Mathieu-Daudé wrote:
>>> Hi Claudio,
>>>
>>> On 22/8/23 14:00, Claudio Fontana wrote:
>>>> Hello,
>>>>
>>>> th
Hi,
this is the first step towards faster migration to disk that we care about the
most,
can it be merged?
Thanks,
Claudio
On 9/8/23 16:22, Steve Sistare wrote:
> Add the migration URI "file:filename[,offset=offset]".
>
> Fabiano Rosas has submitted the unit tests in the s
On 8/30/23 15:09, Claudio Fontana wrote:
> On 8/22/23 15:25, Philippe Mathieu-Daudé wrote:
>> Hi Claudio,
>>
>> On 22/8/23 14:00, Claudio Fontana wrote:
>>> Hello,
>>>
>>> this series is all reviewed,
>>>
>>> and is needed a
On 9/4/23 13:07, Andrew Jones wrote:
> On Mon, Sep 04, 2023 at 10:18:05AM +0200, Claudio Fontana wrote:
>> Hi,
>>
>> I think this discussion from ~2015 could potentially be be historically
>> relevant for context,
>> at the time we had the problem with CNTV
/1435157697-28579-1-git-send-email-marc.zyng...@arm.com/
I could not remember or find if/where the problem was fixed in the end in QEMU,
Ciao,
Claudio
On 9/1/23 21:23, Colton Lewis wrote:
> On Fri, Sep 01, 2023 at 09:35:47AM +0200, Andrew Jones wrote:
>> On Thu, Aug 31, 2023 at 07:00:5
On 8/22/23 15:25, Philippe Mathieu-Daudé wrote:
> Hi Claudio,
>
> On 22/8/23 14:00, Claudio Fontana wrote:
>> Hello,
>>
>> this series is all reviewed,
>>
>> and is needed as a precondition for further work to improve dramatically the
>> performance o
Hello,
this series is all reviewed,
and is needed as a precondition for further work to improve dramatically the
performance of virsh save, virsh restore
when migrating to disk, can it be merged?
Thanks,
Claudio
On 8/16/23 20:28, Fabiano Rosas wrote:
> For v2 I fixed patch 3 which had a h
Apologies, already reviewed, will ping for the merge of the series momentarily,
Claudio
On 8/22/23 14:18, Claudio Fontana wrote:
> Hello,
>
> this patch would still need a review,
>
> and is needed as a precondition for further work to improve dramatically the
> perform
Hello,
this patch would still need a review,
and is needed as a precondition for further work to improve dramatically the
performance of virsh save, virsh restore
when migrating to disk, since Peter Xu already reviewed PATCH 1, 2, 3, maybe it
makes sense to look at 4 too?
Thanks,
Claudio
On
Hello,
this patch is reviewed,
and is needed as a precondition for further work to improve dramatically the
performance of virsh save, virsh restore
when migrating to disk, can it be merged?
Thanks,
Claudio
On 7/25/23 15:26, Fabiano Rosas wrote:
> From: Nikolay Borisov
>
> Ex
Hello,
this series is all reviewed,
and is needed as a precondition for further work to improve dramatically the
performance of virsh save, virsh restore
when migrating to disk, can it be merged?
Thanks,
Claudio
On 7/12/23 21:07, Fabiano Rosas wrote:
> Based-on:
> [PATCH V4 0/2] mig
Hello,
this series is all reviewed,
and is needed as a precondition for further work to improve dramatically the
performance of virsh save, virsh restore
when migrating to disk, can it be merged?
Thanks,
Claudio
On 6/30/23 16:25, Steve Sistare wrote:
> Add the migration URI "file:
Hi all,
we currently have to maintain something downstream for this, since the current
behavior can compound problems on top of existing bad NFS latency,
could someone continue to help reviewing this work?
Thanks,
Claudio
On 6/9/23 22:19, Fabiano Rosas wrote:
> Hi,
>
> The major ch
nning any tests for tcg?
I tried also to run the general make check,
but even in this case the tcg tests do not seem to trigger.
Thanks,
Claudio
> ---
> tests/tcg/s390x/Makefile.target | 1 +
> tests/tcg/s390x/vxeh2_vstrs.c | 88 +
> 2 files ch
_VECTOR, HWCAP_S390_VXRS);
> GET_FEATURE(S390_FEAT_VECTOR_ENH, HWCAP_S390_VXRS_EXT);
> +GET_FEATURE(S390_FEAT_VECTOR_ENH2, HWCAP_S390_VXRS_EXT2);
>
> return hwcap;
> }
Reviewed-by: Claudio Fontana
On Mon, 14 Aug 2023 10:12:35 +0300
Michael Tokarev wrote:
> 14.08.2023 10:01, Claudio Imbrenda wrote:
>
> > I think we could guard the offending item with CONFIG_SOFTMMU for now,
> > to immediately fix the issues you raised, and do the refactoring you
> > propose
On Sat, 12 Aug 2023 12:48:14 +0300
Michael Tokarev wrote:
> 12.08.2023 12:38, Michael Tokarev wrote:
> ...
> > It smells like, at the very least, os-posix.c should be split. We shouldn't
> > include
> > a ton of qemu-system functionality (like very specific option parsing) into
> > qemu-nbd
> >
ns(-)
>
> Sorry, I missed this patch!
>
> If this needs to be in QEMU 8.1 (-rc3 is being tagged today), please
> reply and provide a justification. At this point only security fixes and
> showstoppers will be merged. Thanks!
>
> Applied to my block-next tree for QEMU 8.2:
> https://gitlab.com/stefanha/qemu/commits/block-next
>
> Stefan
Thanks, and in my personal view I think it's ok for 8.2, IIUC it happens during
the migration to file work which is not in 8.1 anyway,
Fabiano correct me here if I am wrong,
Ciao,
Claudio
added Kevin and Hanna for block, since this seems still untouched?
Thanks,
Claudio
On 7/31/23 22:33, Fabiano Rosas wrote:
> We can fail the blk_insert_bs() at init_blk_migration(), leaving the
> BlkMigDevState without a dirty_bitmap and BlockDriverState. Account
> for the possibl
On 8/7/23 10:08, Ilya Leoshkevich wrote:
> On Sun, 2023-08-06 at 13:05 +0200, Claudio Fontana wrote:
>> On 8/5/23 01:03, Ilya Leoshkevich wrote:
>>> Add a small test to prevent regressions.
>>>
>>> Signed-off-by: Ilya Leoshkevich
>>> ---
>>>
re can not be a
> partial match ...
>
> Add a check for this. While at it, fold a number of explicitly handled
> special cases into the generic logic.
>
> Cc: qemu-sta...@nongnu.org
> Reported-by: Claudio Fontana
> Closes: https://lists.gnu.org/archive/html/qemu-devel/2023
he IPM instruction, should it not be a 64bit variable?
bits 0-31 are left unchanged / are uninteresting, is that enough to avoid
having to use a properly sized variable?
I see that this is done elsewhere in the tests (sometimes a 64bit variable is
used, sometimes just 'int'), so I assume it
On 8/4/23 11:20, Thomas Huth wrote:
> On 04/08/2023 11.00, Claudio Fontana wrote:
>> Hi,
>>
>> On 7/21/23 11:08, Claudio Fontana wrote:
>>>
>>> Hello Cornelia, Richard,
>>>
>>> I had some strange behavior in an s390x TCG VM that I am de
Hi,
On 7/21/23 11:08, Claudio Fontana wrote:
>
> Hello Cornelia, Richard,
>
> I had some strange behavior in an s390x TCG VM that I am debugging,
>
> and configured latest upstream QEMU with --enable-debug --enable-debug-tcg
>
> and I am running the qemu binary wi
On 7/31/23 18:21, Xiaoyao Li wrote:
> From: Chao Peng
>
> Switch to KVM_SET_USER_MEMORY_REGION2 when supported by KVM.
>
> With KVM_SET_USER_MEMORY_REGION2, QEMU can set up memory region that
> backen'ed both by hva-based shared memory and gmem fd based private
> memory.
>
> Signed-off-by: Chao
On 8/1/23 18:48, Claudio Fontana wrote:
> On 7/31/23 18:21, Xiaoyao Li wrote:
>> Signed-off-by: Xiaoyao Li
>> ---
>> include/exec/memory.h | 9 +
>> softmmu/memory.c | 5 +
>> 2 files changed, 14 insertions(+)
>>
>> diff --git a/
On 7/31/23 18:21, Xiaoyao Li wrote:
> Signed-off-by: Xiaoyao Li
> ---
> include/exec/memory.h | 9 +
> softmmu/memory.c | 5 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/include/exec/memory.h b/include/exec/memory.h
> index 61e31c7b9874..e119d3ce1a1d 100644
> --- a/inc
On 7/31/23 13:31, Claudio Fontana wrote:
> On 7/21/23 11:08, Claudio Fontana wrote:
>>
>> Hello Cornelia, Richard,
>>
>> I had some strange behavior in an s390x TCG VM that I am debugging,
>>
>> and configured latest upstream QEMU with --enable-debug --enab
On 7/21/23 11:08, Claudio Fontana wrote:
>
> Hello Cornelia, Richard,
>
> I had some strange behavior in an s390x TCG VM that I am debugging,
>
> and configured latest upstream QEMU with --enable-debug --enable-debug-tcg
>
> and I am running the qemu binary with -d uni
e exception has been raised,
> we will have unwound the pages locked for translation and the
> problem does not arise. There are plenty of other updates to
> LowCore while delivering an interrupt/exception; trans_exc_code
> does not need to be special.
>
> Reported-by: Claudio
On 7/28/23 16:28, Richard Henderson wrote:
> On 7/28/23 07:23, Claudio Fontana wrote:
>>> It is a test environment for building packages, so the guest at the time of
>>> the error is running ./configure for the package swig-v4.1.1.tar.gz
>>>
>>> checking bui
On 7/28/23 16:40, Claudio Fontana wrote:
> On 7/28/23 16:28, Richard Henderson wrote:
>> On 7/28/23 07:23, Claudio Fontana wrote:
>>>> It is a test environment for building packages, so the guest at the time
>>>> of the error is running ./configure f
On 7/28/23 15:45, Claudio Fontana wrote:
> On 7/28/23 15:33, Richard Henderson wrote:
>> On 7/28/23 06:29, Claudio Fontana wrote:
>>> On 7/27/23 19:41, Richard Henderson wrote:
>>>> On 7/21/23 02:08, Claudio Fontana wrote:
>>>>> Thread 3 "
On 7/27/23 19:41, Richard Henderson wrote:
> On 7/21/23 02:08, Claudio Fontana wrote:
>> Thread 3 "qemu-system-s39" received signal SIGABRT, Aborted.
>> [Switching to Thread 0x753516c0 (LWP 215975)]
>> (gdb) bt
>> #0 0x7730dabc in __pthread_kill_im
On 7/28/23 15:33, Richard Henderson wrote:
> On 7/28/23 06:29, Claudio Fontana wrote:
>> On 7/27/23 19:41, Richard Henderson wrote:
>>> On 7/21/23 02:08, Claudio Fontana wrote:
>>>> Thread 3 "qemu-system-s39" received signal SIGABRT, Aborted.
>>>
.. adding Alex, maybe something related to multithreaded TCG?
On 7/21/23 11:08, Claudio Fontana wrote:
>
> Hello Cornelia, Richard,
>
> I had some strange behavior in an s390x TCG VM that I am debugging,
>
> and configured latest upstream QEMU with --enable-debug --enable-de
ess fault: interruption code 0011
ilc:2 in libc.so.6[3ff87a8+1c9000]
[ 2269s] [ 2243.904433][ T8318] Failing address: 02aa0f73f000 TEID:
000002aa0f73f800
[ 2269s] [ 2243.904952][ T8318] Fault in primary space mode while using user
ASCE.
[ 2269s] [ 2243.905405][ T8318] AS:057841c7 R3:01fdc007
S:0398c000 P:0400
I thought they might possibly be related..
Thanks for any suggestion,
Claudio
On 7/17/23 12:37, Igor Mammedov wrote:
> On Mon, 17 Jul 2023 10:32:33 +0200
> Claudio Fontana wrote:
>
>> Hello Igor,
>>
>> thanks for getting back to me on this,
>>
>> On 7/14/23 11:51, Igor Mammedov wrote:
>>> On Wed, 5 Jul 2023 10:12:40 +020
On 7/17/23 10:32, Claudio Fontana wrote:
> Hello Igor,
>
> thanks for getting back to me on this,
>
> On 7/14/23 11:51, Igor Mammedov wrote:
>> On Wed, 5 Jul 2023 10:12:40 +0200
>> Claudio Fontana wrote:
>>
>>> Hi all, partially resurrecting an
Hello Igor,
thanks for getting back to me on this,
On 7/14/23 11:51, Igor Mammedov wrote:
> On Wed, 5 Jul 2023 10:12:40 +0200
> Claudio Fontana wrote:
>
>> Hi all, partially resurrecting an old thread.
>>
>> I've seen how for Epyc something special was done in
r AMD?
Thanks,
Claudio
On 9/1/20 17:57, Babu Moger wrote:
> To support some of the complex topology, we introduced EPYC mode apicid
> decode.
> But, EPYC mode decode is running into problems. Also it can become quite a
> maintenance problem in the future. So, it was decided to rem
) and that the options become introspectable via QMP this way.
> So let's start moving more switches into this option group, starting
> with "-chroot" now.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Claudio Imbrenda
> ---
> docs/about/depr
On Thu, 29 Jun 2023 13:12:26 +0200
Thomas Huth wrote:
> On 29/06/2023 12.58, Claudio Imbrenda wrote:
> > On Thu, 29 Jun 2023 12:48:21 +0200
> > Thomas Huth wrote:
> >
> >> start.S currently cannot be compiled with Clang 16 and binutils 2.40:
> >>
&g
30510143925.4094-4-quint...@redhat.com>
> Reviewed-by: Thomas Huth
Reviewed-by: Claudio Imbrenda
> Signed-off-by: Thomas Huth
> ---
> pc-bios/s390-ccw/helper.h| 2 +-
> pc-bios/s390-ccw/s390-ccw.h | 7 +++
> pc-bios/s390-ccw/virtio-scsi.h | 2 +-
> pc-bi
On Thu, 29 Jun 2023 12:48:21 +0200
Thomas Huth wrote:
> start.S currently cannot be compiled with Clang 16 and binutils 2.40:
>
> ld: start.o(.text+0x8): misaligned symbol `__bss_start' (0xc1e5) for
> relocation R_390_PC32DBL
>
> According to the built-in linker script of ld, the symbol _
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/s390/cio/cio.h?id=cd6b4f27b9bb2a
>
> So we should get rid of the __u* in the s390-ccw bios now finally, too.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Claudio Imbrenda
> ---
> Ba
for aligning it to page
> boundaries.
>
> Signed-off-by: Thomas Huth
Reviewed-by: Claudio Imbrenda
> ---
> pc-bios/s390-ccw/s390-ccw.h | 1 -
> pc-bios/s390-ccw/main.c | 1 -
> pc-bios/s390-ccw/netmain.c | 1 -
> pc-bios/s390-ccw/start.S| 6 ++
> 4 files ch
390x/ folder already, so let's adjust start.S accordingly.
>
> Reviewed-by: Cédric Le Goater
> Signed-off-by: Thomas Huth
Reviewed-by: Claudio Imbrenda
> ---
> pc-bios/s390-ccw/start.S | 136 +++
> 1 file changed, 68 insertions(+), 68 del
CK_SIZE - 160 /* Set up stack */
>
> /* clear bss */
> -larl%r2,__bss_start
> +larl%r2,.bss
> larl%r3,_end
since we are here, do you have guarantees that _end is always correctly
aligned?
if so:
Reviewed-by: Claudio Imbrenda
> slgr%r3,%r2/* get sizeof bss */
> ltgr%r3,%r3/* bss empty? */
at it, add a proper STACK_SIZE macro for the stack size
> instead of using magic numbers (this is also required for the following
> patch).
>
> Reviewed-by: Christian Borntraeger
> Reviewed-by: Cédric Le Goater
> Signed-off-by: Thomas Huth
with Marc's suggest
care about
> KVM, we really want to test for TCG.
>
> Signed-off-by: Philippe Mathieu-Daudé
I don't remember anymore, but what about qtest ? It is usually the forgotten
case in these kind of tests... so much complexity :-)
Ciao,
Claudio
> ---
> hw/ppc/spapr.c | 2 +
1 - 100 of 1007 matches
Mail list logo
