ounds working to you?
I didn't know much about these options, cool, thanks for the explanation.
My only concern is that I'd have to restart the QEMU process for each iteration.
Honestly I've never measured the impact it would have but I fear that it would
be noticeable since the goal is to restore many times a second. What do you
think?
(Also, snapshots conveniently take care of the disk as well, but this shouldn't
be too big of a deal.)
Thanks,
Best
Marco
dding the support for the
mapped-ram feature for savevm/loadvm snapshots, which is a
prerequisite for my hotreload feature.
mapped-ram is currently supported only in (file) migration.
What's missing from this patch to have it working completely, is the
handling of zero pages. Differently from migration, with snapshots pages
are not all zero prior to the restore and must therefore be handled.
I hope I summarized in an understandable way, if not I'll be happy to
further clarify :)
Thanks for the feedback!
Best
Marco
there's a 1
> for that page in the bitmap, then we don't really care what's in the
> file_bmap.
>
> If we implement generic snapshot + mapped-ram + zero page then you could
> probably simply OR your dirty bitmap on top of the file_bmap.
>
> Does that makes sense? I might be missing something, I'm looking at a
> bunch of threads before going on vacation.
It makes sense, but special handling for zero pages instead of simply
ORing the two maps could improve performance.
If dirty = true and file_bmap = false, instead of reading the zero
page from the snapshot I can simply memset to 0 as above.
Enjoy your vacation :)
Thank you.
Best,
Marco
n that case.
Perhaps I'm missing your point; if a page was zero in the snapshot
and then gets dirtied, I need to zero it out. But yeah, the code will be
different and for my specific use case I don't absolutely need
mapped-ram snapshots restore to fully work.
Thank you.
Best,
Marco
ence
> between mapped-ram=on vs off.
Repeating the same experiment as above, without mapped-ram,
I obtain +48% in restore time compared to mapped-ram and,
therefore, a +18% wrt to the mapped-ram with zeroing.
(It should be noted that mapped-ram without zeroing leaves
the restored vm in an inconsistent state).
At the moment I don't have numbers regarding savevm.
Thanks!
Best,
Marco
o page, I feel like the
"is present in the migration file" and "is zero page" info should
be better separated.
Best,
Marco
seek is always implemented and works
(except for SEEK_END).
> It seems redundant that way.
I'm not sure I understand what you mean here.
TLDR: QIOChannelBlock is already always seekable, this patch just adds
the capability explicitly so that it will work with mapped-ram.
Best
Marco
ork with QIOChannelBlock.
You can have a look at the patch where those functions were
introduced here [0].
Best,
Marco
[0] https://lore.kernel.org/qemu-devel/20240229153017.2221-4-faro...@suse.de/
king is managed internally by the
pread(2) and co. functions, which perform I/O operations at
specified offsets without altering the file descriptor's position.
I hope this clarifies :)
Best,
Marco
irst step in making QIOChannelBlock compatible with
mapped-ram feature that requires it since mapped-ram uses
io_preadv and io_pwritev methods.
Best,
Marco
Hello Fabiano,
First of all thanks a lot for the quick follow up to my issue!
I just want to point out that with only mapped-ram enabled (without
multifd) savevm/loadvm do not lead to a crash but just to an error
according to my (few) experiments (on upstream).
Ciao
Marco
On Thursday, March
ned-off-by: Marco Cavenati
---
Hello,
Please note that this depends on my previous fix [0] (which has already
been reviewed) in order to work.
The code in this patch is inspired by commit
0478b030fa2530cbbfc4d6432e8e39a16d06865b that adds the same feature to
QIOChannelFile.
Thank you,
Regards
VMState")
Signed-off-by: Marco Cavenati
---
migration/channel-block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/channel-block.c b/migration/channel-block.c
index fff8d87094..b0477f5b6d 100644
--- a/migration/channel-block.c
+++ b/migration/ch
Thanks Peter for your time!
Marco Palumbi
Senior Cryptography Engineer
PO Box: 9639
Masdar City, Abu Dhabi, UAE
M: +39 349 786 0737
E: marco.palu...@tii.ae
tii.ae
This email and any files transmitted with it are strictly confidential and
intended solely for the use of the individual or
From: Marco Palumbi
The order of the RX and TX interrupts are swapped.
This commit fixes the order as per the following documents:
* https://developer.arm.com/documentation/dai0505/latest/
* https://developer.arm.com/documentation/dai0521/latest/
* https://developer.arm.com/documentation
ce.
Moving them to the correct location makes shuffling of .tmp vector
registers work as expected.
Signed-off-by: Marco Liebel
---
target/hexagon/mmvec/decode_ext_mmvec.c | 8 +++
tests/tcg/hexagon/hvx_misc.c| 31 +
2 files changed, 35 insertions(+), 4
The order in which instructions are generated by gen_insn() influences
assignment to tmp registers. During generation, tmp instructions (e.g.
generate_V6_vassign_tmp) use vreg_src_off() to determine what kind of
register to use as source. If some instruction (e.g.
generate_V6_vmpyowh_64_acc) uses a
test_vshuff checks that the vshuff instruction works correctly when
both vector registers are the same. Using vshuff in this way is
undefined and will be rejected by the compiler in a future version of
the toolchain.
Signed-off-by: Marco Liebel
---
tests/tcg/hexagon/hvx_misc.c | 45
Signed-off-by: Marco Liebel
---
tests/docker/dockerfiles/debian-hexagon-cross.docker | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/docker/dockerfiles/debian-hexagon-cross.docker
b/tests/docker/dockerfiles/debian-hexagon-cross.docker
index 5308ccb8fe..b99d99f943
> -Original Message-
> From: Peter Maydell
> Sent: Dienstag, 21. März 2023 18:20
> To: Marco Liebel (QUIC)
> Cc: qemu-devel@nongnu.org; Taylor Simpson ;
> Matheus Bernardino (QUIC)
> Subject: Re: [PATCH 2/2] Add test for storing .new vector
>
> WARNING:
Hexagon toolchain version 16.0.0 fixes a bug where the ecoding of
storing a .new vector was incorrect. This resulted in an incorrect
valued being stored. The test checks that the correct value is used.
Signed-off-by: Marco Liebel
---
tests/tcg/hexagon/hvx_misc.c | 29
Updates the hexagon toolchain and adds a test for a bug that was fixed
by the new version.
Marco Liebel (2):
Use hexagon toolchain version 16.0.0
Add test for storing .new vector
.../dockerfiles/debian-hexagon-cross.docker | 2 +-
tests/tcg/hexagon/hvx_misc.c | 29
Signed-off-by: Marco Liebel
---
tests/docker/dockerfiles/debian-hexagon-cross.docker | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/docker/dockerfiles/debian-hexagon-cross.docker
b/tests/docker/dockerfiles/debian-hexagon-cross.docker
index 5308ccb8fe..b99d99f943
Signed-off-by: Marco Liebel
---
target/hexagon/dectree.py | 396 ---
target/hexagon/gen_analyze_funcs.py | 135 +++---
target/hexagon/gen_helper_funcs.py | 338 +++--
target/hexagon/gen_helper_protos.py | 165 ---
target/hexagon
Replace python 2 format string with f-strings
Signed-off-by: Marco Liebel
---
target/hexagon/gen_analyze_funcs.py | 115 -
target/hexagon/gen_helper_funcs.py | 54 ++--
target/hexagon/gen_helper_protos.py | 10 +-
target/hexagon/gen_idef_parser_funcs.py | 8 +-
target
Replaces python 2 format strings with f-strings and applies black code
style to all python files in target/hexagon.
Marco Liebel (2):
Use f-strings in python scripts
Use black code style for python scripts
target/hexagon/dectree.py | 396 +++--
target/hexagon
Replace python 2 format string with f-strings
Signed-off-by: Marco Liebel
---
target/hexagon/gen_analyze_funcs.py | 115 -
target/hexagon/gen_helper_funcs.py | 54 ++--
target/hexagon/gen_helper_protos.py | 10 +-
target/hexagon/gen_idef_parser_funcs.py | 8 +-
target
> -Original Message-
> From: Taylor Simpson
> Sent: Dienstag, 14. März 2023 18:54
> To: Marco Liebel (QUIC) ; qemu-
> de...@nongnu.org
> Subject: RE: [PATCH] Use f-strings in python scripts
>
>
>
> > -Original Message-
> > From: Marco Li
Replace python 2 format string with f-strings
Signed-off-by: Marco Liebel
---
target/hexagon/gen_helper_funcs.py | 54 ++--
target/hexagon/gen_helper_protos.py | 10 +-
target/hexagon/gen_idef_parser_funcs.py | 8 +-
target/hexagon/gen_op_attribs.py| 4 +-
target/hexagon
Some registers are defined to have immutable bits, this commit
will implement that behavior.
Signed-off-by: Marco Liebel
---
target/hexagon/genptr.c | 44 -
tests/tcg/hexagon/Makefile.target | 1 +
tests/tcg/hexagon/reg_mut.c | 152 ++
3
> -Original Message-
> From: Taylor Simpson
> Sent: Mittwoch, 21. Dezember 2022 21:06
> To: Marco Liebel ; Marco Liebel (QUIC)
> ; qemu-devel@nongnu.org
> Cc: Brian Cain
> Subject: RE: [PATCH v2] Hexagon (target/hexagon) implement mutability
> mask for GPRs
&g
> > +#define WRITE_REG_IN_PACKET(reg_name, output, input) \
> > +asm volatile("{ " reg_name " = %1 }\n\t" \
>
> This is no different from the WRITE_REG above. Instructions on a line with
> no curly braces are a single packet.
>
Understood. The feedback on Brian's patch said to write tests t
Some registers are defined to have immutable bits, this commit
will implement that behavior.
Signed-off-by: Marco Liebel
---
This incorporates the feedback given on Brian's patch
target/hexagon/genptr.c | 43 -
tests/tcg/hexagon/Makefile.target | 3 +
tests/tcg/he
Closing issue as it has been migrated to https://gitlab.com/qemu-
project/qemu/-/issues/279
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1911351
Title:
x86-64 MTTCG Does not update page table entr
Closing issue as it has been migrated to https://gitlab.com/qemu-
project/qemu/-/issues/279
** 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/1911
This issue has been migrated to gitlab issue #279. See
https://gitlab.com/qemu-project/qemu/-/issues/279
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #279
https://gitlab.com/qemu-project/qemu/-/issues/279
--
You received this bug notification because you are a member of qemu-
dev
Fixed in qemu-s390x version 5.2.0 (Debian 1:5.2+dfsg-10)
** 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/1862986
Title:
qemu-s390x segf
The config is from 5.12-rc4, and the earliest kernel version that should
reproduce this is 5.12-rc1.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1920934
Title:
Heap-use-after-free in io_writex /
Yes, I have:
commit 5ca634afcf83215a9a54ca6e66032325b5ffb5f6 (HEAD -> master, origin/master,
origin/HEAD)
Merge: c95bd5ff16 cffb446e8f
Author: Peter Maydell
Date: Mon Mar 22 18:50:25 2021 +
Or another branch?
--
You received this bug notification becau
Public bug reported:
qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0
We've encountered that booting the Linux kernel in TCG mode, results in
a racy heap-use-after-free. The bug can be detected by ASan [A], but in
the majority of runs results in a crashing kernel [B].
To reprodu
We only tested it on x86-64 and aarch64, but we couldn't repro on arm.
It is possible that this affects other platforms as well, but note that
this is specifically mentioned in the qemu wiki as one of the cases that
should be covered when porting mttcg to a new platform:
https://wiki.qemu.org/Featu
** Description changed:
It seems like the qemu tcg code for x86-64 doesn't write the access and
- dirty flags of the page table entries atomically. Instead, they first
+ dirty bits of the page table entries atomically. Instead, they first
read the entry, see if they need to set the page table
Public bug reported:
It seems like the qemu tcg code for x86-64 doesn't write the access and
dirty flags of the page table entries atomically. Instead, they first
read the entry, see if they need to set the page table entry, and then
overwrite the entry. So if you have two threads running at the s
Public bug reported:
Bug in QEMU 5.0.0:
virtiofsd exits when iommu_platform is enabled after virtiofs driver is loaded.
If iommu_platform is disabled the guest immediately locks up as a result of the
configured PCIe-Passthrough.
Host system:
- Arch Linux amd64
- AMD Ryzen Platform
- QEMU 5.0.0
This still happens on qemu 5.0
Steps to reproduce:
# install packages
dpkg --add-architecture s390x
apt update
apt install qemu-user libc6:s390x libstdc++6:s390x libfontconfig1:s390x
libxcb1:s390x
apt install g++-s390x-linux-gnu
# create dummy binary
echo 'int main(){}'| s390x-linux-gnu-g++ -x
I can also reproduce this in a debian:sid docker container on x86_64, so
this might not be related to the host CPU architecture
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1862986
Title:
qemu-s39
** Attachment added: "A smaller test binary that also crashes"
https://bugs.launchpad.net/qemu/+bug/1862986/+attachment/5331362/+files/hello_world.exe
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs
Thanks for taking a look. With the binary I posted, the steps to
reproduce are:
dpkg --add-architecture s390x && apt update && apt install qemu-user
wget libc6:s390x libstdc++6:s390x libfontconfig1:s390x libxcb1:s390x -y
&& wget
https://bugs.launchpad.net/qemu/+bug/1862986/+attachment/5331331/+fil
** Attachment added: "A test binary"
https://bugs.launchpad.net/qemu/+bug/1862986/+attachment/5331331/+files/test_bitcoin_orig
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1862986
Title:
qemu-
Public bug reported:
All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault
when run on an aarch64 odroid Ubuntu.
Steps to reproduce:
root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x
"/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin
Joel is on vacation so here it is again.
> Begin forwarded message:
>
> From: Alistair Francis
> Subject: Re: [j...@sing.id.au: atomic failures on qemu-system-riscv64]
> Date: June 5, 2019 at 7:19:53 PM GMT+1
> To: "j...@sing.id.au" , "pal...@sifive.com"
>
> Cc: "ma...@decred.org" , "m...@carl
FYI: we've hit this as will with syzkaller testing; this is still
reproducible as-is with latest qemu (commit a6ae238), and the latest
Linux kernel (5.1-rc7).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/
Thanks Peter,
Signed-off-by: Marco A L Barbosa
On Thu, Jan 11, 2018 at 4:52 PM, Peter Maydell
wrote:
> On 11 January 2018 at 18:37, Marco A L Barbosa wrote:
> > ---
> > linux-user/elfload.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
>
> This is
https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg01298.html
On Thu, Jan 11, 2018 at 4:37 PM, Marco A L Barbosa
wrote:
> ---
> linux-user/elfload.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index
---
linux-user/elfload.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 20f3d8c2c3..32a47674e6 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -1354,7 +1354,7 @@ struct exec
~
Public bug reported:
When executing an android native binary using qemu in user mode, the
program fail with the message
FATAL: kernel did not supply AT_SECURE
Android uses bionic libc.The linker requires that AT_SECURE is provided
in the auxiliary vector, but qemu does not provide the entry.
Th
I submitted a new patch. Thanks.
On Thu, Oct 5, 2017 at 7:35 AM, Laurent Vivier wrote:
> On 05/10/2017 12:24, Marco A L Barbosa wrote:
> > I doesn't look really trivial...
> >
> > To manage the buf field you must read buf_size and it cannot be done
> in
&g
>
> I doesn't look really trivial...
>
> To manage the buf field you must read buf_size and it cannot be done in
> a generic way: you must define a function to translate the buffer, use
> IOCTL_SPECIAL() with RNDADDENTROPY and RNDGETPOOL.
>
> You should send your patch using "git send-email" or "gi
I don't know how (and if it is necessary) to add buf field to
rand_pool_info struct. See
https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/include/uapi/linux/random.h#L17
Signed-off-by: Marco A L Barbosa
---
linux-user/ioctls.h| 7 +++
linux
On Thu, 2014-09-04 at 09:10 -0400, Gabriel L. Somlo wrote:
> On Thu, 04 Sep 2014 08:43:12, Marco Minetti wrote:
> > The experiments for running MacOSXon KVM/QEMU I followed are here:
> > http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
> >
> [...]
> >
> >
The experiments for running MacOSXon KVM/QEMU I followed are here:
http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1358722
Title:
latest acpi commits
Public bug reported:
qemu release 2.1.0
Hi,
I've found a regression on MacOSX guest (10.9.4) after merging the following
commits
18045fb9f457a0f0cba2bd113c748a2dcb4ed39e pc: future-proof
migration-compatibility of ACPI tables
868270f23d8db2cce83e4f082fe75e8625a5fbf9 acpi-build: tweak acpi mig
ow to enable nehalem.
Could anyone give me some hints on this issue?
thanks in advance
Marco
> Date: Mon, 14 Mar 2011 21:06:55 +0200
> From: g...@redhat.com
> To: mc...@hotmail.it
> CC: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] Windows 7 on pure qemu-0.14
>
> On
ted so far.
Is there any code practice to follow? Which source files should I put my
hands on?
Thank you very much in advance for your help....
m
--
Marco Boni
Information Engineering Department
University of Siena
Room 223
Via Roma, 56
53100 Siena
ITALY
Office: +39 0577 234850 (10
me a BSOD with this error:
Stop: 0x005D
(0x78BFBF9,0x,0x,0x
Is there a way to solve this issue?
Any hint is appreciated, thanks a lot in advance
Marco
Hi to alll,
I'm a student of University Rome Sapienza.
I'm working with qemu 0.9.1 for my thesis
and I'm trying to understand how a full-emulation (qemu without kvm or kqemu)
Virtual Machine works at low level.
I studied your smart source code but I don't understand
how qemu manages emul
nt it every time a guest instruction has to be executed.
Can you please give me some hints on how to realize it, i.e. which files
I should put my hands on?
Thanks a lot
m
--
Marco Boni
Mobile: +39 335 607 9353
Email: mb.b...@gmail.com
Skype: m.boni
Hi, all
I'm a developer of debian-live and I am not subscribed to this list, so please
CC me in the replies.
First, many thanks for this software to Fabrice Bellard and all developers.
As subject says, when I launch qemu-system-x86_64 (I'm on debian/sid amd64
with an athlon64 dual core), with k
Hi, all
I'm a developer of debian-live and I am not subscribed to this list, so please
CC me in the replies.
First, many thanks for this software to Fabrice Bellard and all developers.
As subject says, when I launch qemu-system-x86_64 (I'm on debian/sid amd64
with an athlon64 dual core), with k
I will be out of the office starting 12/22/2006 and will not return until
01/01/2007.
Wish you Happy Holidays and Happy new Year.
Marco
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Hi, all
I'm a developer of debian-live and I am not subscribed to this list, so please
CC me in the replies.
First, many thanks for this software to Fabrice Bellard and all developers.
As subject says, when I launch qemu-system-x86_64 (I'm on debian/sid amd64
with an athlon64 dual core), with k
volunteers? CS research projects?
How about MMIX?
http://en.wikipedia.org/wiki/MMIX
There is already a simulator/assembler here:
http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html
Marco
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http
t you just build a crosscompiler and cross-binutils and
then use qemu-sparc instead of qemu-system-sparc, i.e. using
user emulation instead of whole system emulation ?
Marco
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/ma
Installing the latest Vista Beta2 (build 5456), the systemgenerates a blue screen: STOP: 0x00A5 (0x0001000B, 0x50434146, 0xFFD05050, 0x)This is likely a problem in the QEMU ACPI implementation (see microsoft site),any idea how to solve this?Marco_
probably be faster than qemu-system,
as it doesn't have to emulate the os and hardware.
Marco
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
error d144 exactly, is an ide.c problem?My configuration:virtual machine:memory 512hda 20GB rawcdrom isooptions -win2k-hack and without-- Marco
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Brad Campbell wrote:
none 768M 137M 632M 18% /tmp <-- not sure why it
says none.. it's tmpfs
change the none to tmpfs in /etc/fstab. normally the mount point goes
there, but tmpfs (and proc, for example) don't have a mount point so you
can put anything t
en allow the guest to communicate
with the host and the guest to also reach the internet.
Hope this helps,
Marco
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
78 matches
Mail list logo
