The timeout mechanism won't work if SIGALRM is blocked. This changes
unmasks SIGALRM when the timer is installed. This doesn't completely
solve the problem, as the fuzzer could trigger some device activity that
re-masks SIGALRM. However, there are currently no inputs on OSS-Fuzz
that re-mask SIGALR
The code mistakenly relied on address_space_translate to store the
length remaining until the next memory-region. We care about this
because when there is RAM or sparse-memory neighboring on an MMIO
region, we should only write up to the border, to prevent inadvertently
invoking MMIO handlers withi
From: Darren Kenny
Should have done this much sooner given the amount of reviewing I'm
already doing in this area.
Signed-off-by: Darren Kenny
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alexander Bulekov
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/
On 8/23/21 11:42 AM, Philipp Tomsich wrote:
+static bool trans_clmul(DisasContext *ctx, arg_clmul *a)
+{
+REQUIRE_ZBC(ctx);
+return gen_arith(ctx, a, gen_helper_clmul);
+}
+
+
+static bool trans_clmulh(DisasContext *ctx, arg_clmulr *a)
+{
+REQUIRE_ZBC(ctx);
+return gen_arith(ctx,
The code mistakenly relied on address_space_translate to store the
length remaining until the next memory-region. We care about this
because when there is RAM or sparse-memory neighboring on an MMIO
region, we should only write up to the border, to prevent inadvertently
invoking MMIO handlers withi
Hi Paolo,
(Resending, since I didn't send the original PR cover-letter to
qemu-devel)
The following changes since commit d42685765653ec155fdf60910662f8830bdb2cef:
Open 6.2 development tree (2021-08-25 10:25:12 +0100)
are available in the Git repository at:
https://gitlab.com/a1xndr/qemu/ f
Using ITIMER_VIRTUAL is a bad idea, if the fuzzer hits a blocking
syscall - e.g. ppoll with a NULL timespec. This causes timeout issues
while fuzzing some block-device code. Fix that by using wall-clock time.
This might cause inputs to timeout sometimes due to scheduling
effects/ambient load, but i
We have some configs for devices such as the AC97 and ES1370 that were
not matching memory-regions correctly, because the configs provided
lowercase names. To resolve these problems and prevent them from
occurring again in the future, convert both the pattern and names to
lower-case, prior to check
Using a custom timeout is useful to continue fuzzing complex devices,
even after we run into some slow code-path. However, simply adding a
fixed timeout to each input effectively caps the maximum input
length/number of operations at some artificial value. There are two
major problems with this:
1.
The timeout mechanism won't work if SIGALRM is blocked. This changes
unmasks SIGALRM when the timer is installed. This doesn't completely
solve the problem, as the fuzzer could trigger some device activity that
re-masks SIGALRM. However, there are currently no inputs on OSS-Fuzz
that re-mask SIGALR
By default, -fsanitize=fuzzer instruments all code with coverage
information. However, this means that libfuzzer will track coverage over
hundreds of source files that are unrelated to virtual-devices. This
means that libfuzzer will optimize inputs for coverage observed in timer
code, memory APIs e
From: Darren Kenny
Should have done this much sooner given the amount of reviewing I'm
already doing in this area.
Signed-off-by: Darren Kenny
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alexander Bulekov
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/
From: Qiuhao Li
To keep me cc-ed when something changes. Suggested by Alexander.
https://lists.gnu.org/archive/html/qemu-devel/2021-08/msg03631.html
Signed-off-by: Qiuhao Li
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Alexander Bulekov
Reviewed-by: Darren Kenny
---
MAINTAINERS | 1 +
On Tue, 24 Aug 2021 21:48:30 -0300
Daniel Henrique Barboza wrote:
> As done in hw/acpi/memory_hotplug.c, pass an empty string if dev->id
> is NULL to qapi_event_send_mem_unplug_error() to avoid relying on
> a behavior that can be changed in the future.
>
> Suggested-by: Markus Armbruster
> Sign
On Tue, 24 Aug 2021 21:48:29 -0300
Daniel Henrique Barboza wrote:
> qapi_event_send_mem_unplug_error() deals with @device being NULL by
> replacing it with an empty string ("") when emitting the event. Aside
> from the fact that this behavior (qapi visitor mapping NULL pointer to
> "") can be pat
Sorry, Peter - I forgot to indicate that this is a SUBSYSTEM PR.
-Alex
On 210825 0942, Alexander Bulekov wrote:
> Hi Paolo,
>
> (Resending, since I didn't send the original PR cover-letter to
> qemu-devel)
>
> The following changes since commit d42685765653ec155fdf60910662f8830bdb2cef:
>
> Op
On Tue, 24 Aug 2021 21:48:33 -0300
Daniel Henrique Barboza wrote:
> At this moment we only provide one event to report a hotunplug error,
> MEM_UNPLUG_ERROR. As of Linux kernel 5.12 and QEMU 6.0.0, the pseries
> machine is now able to report unplug errors for other device types, such
> as CPUs.
>
On 8/25/21 2:27 PM, Mark Cave-Ayland wrote:
> On 25/08/2021 11:43, Philippe Mathieu-Daudé wrote:
>
>> +Leon3 maintainers
>
> Note that despite its presence in CPUSPARCState MXCC isn't part of the
> SPARC CPU but defined as part of the sun4m architecture, so I'm not sure
> it even exists in LEON3
On 8/25/21 1:37 AM, David Gibson wrote:
On Tue, Aug 24, 2021 at 01:30:19PM -0300, Daniel Henrique Barboza wrote:
From: Gustavo Romero
Similar to the previous patch, user write on some PowerPC
PMU regs, in this case, MMCR0, is limited. Create a new
function to handle that.
Ok.. ok, this fi
On 8/25/21 2:19 AM, David Gibson wrote:
On Tue, Aug 24, 2021 at 01:30:20PM -0300, Daniel Henrique Barboza wrote:
This patch adds the barebones of the PMU logic by enabling cycle
counting, done via the performance monitor counter 6. The overall logic
goes as follows:
- a helper is added to co
On 8/25/21 2:31 AM, David Gibson wrote:
On Tue, Aug 24, 2021 at 01:30:22PM -0300, Daniel Henrique Barboza wrote:
The PMU is already counting cycles by calculating time elapsed in
nanoseconds. Counting instructions is a different matter and requires
another approach.
This patch adds the capab
On Tue, Aug 24, 2021 at 01:15:17PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> There is no conflict and no dependency if we have parallel writes to
> different subclusters of one cluster when the cluster itself is already
> allocated. So, relax extra dependency.
>
...
> So small writes are more i
Since we are not using Launchpad anymore, there is no more need for
this script.
Signed-off-by: Thomas Huth
---
scripts/show-fixed-bugs.sh | 91 --
1 file changed, 91 deletions(-)
delete mode 100755 scripts/show-fixed-bugs.sh
diff --git a/scripts/show-fixed-
On 8/25/21 4:21 PM, Thomas Huth wrote:
> Since we are not using Launchpad anymore, there is no more need for
> this script.
>
> Signed-off-by: Thomas Huth
> ---
> scripts/show-fixed-bugs.sh | 91 --
> 1 file changed, 91 deletions(-)
> delete mode 100755 scrip
Hi,
This is a repost of RFCv3 [1] rebased using current David's ppc-for-6.2.
The reason of this repost is that the kernel side changes got accepted
in the maintainer's tree [2], meaning that this series is now an implementation
of the future FORM2 kernel support in the pseries kernel.
In a POWER
The pSeries machine will support a new NUMA affinity form, FORM2.
This new FORM will be negotiated via ibm,architecture-vec5 during
CAS. All artifacts and assumptions that are currently on use for
FORM1 affinity will be deprecated in a guest that chooses to use
FORM2. This means that we're going to
The upcoming FORM2 NUMA affinity will support asymmetric NUMA topologies
and doesn't need be concerned with all the legacy support for older
pseries FORM1 guests.
We're also not going to calculate associativity domains based on numa
distance (via spapr_numa_define_associativity_domains) since the
The main feature of FORM2 affinity support is the separation of NUMA
distances from ibm,associativity information. This allows for a more
flexible and straightforward NUMA distance assignment without relying on
complex associations between several levels of NUMA via
ibm,associativity matches. Anoth
When spapr_numa_associativity_init() was introduced it was being
called from spapr_machine_init(), where we have pointers to a
SpaprMachineState and a MachineState. Having both being passed
as params spared us from calling a macro to get the MachineState.
Previous patches moved the function away f
FORM2 NUMA affinity is prepared to deal with memory/cpu less
NUMA nodes. This is used by the DAX KMEM driver to locate a
PAPR SCM device that has a different latency than the original
NUMA node from the regular memory.
Move this verification to FORM1 affinity code.
Signed-off-by: Daniel Henrique
On Aug 25 15:08, Philippe Mathieu-Daudé wrote:
> On 8/25/21 1:34 PM, Klaus Jensen wrote:
> > On Aug 24 16:11, Philippe Mathieu-Daudé wrote:
> >> Now that all qemu_vfio_dma_map() callers provide an Error* argument,
> >> fill it with relevant / more descriptive message. Reduce 'ret'
> >> (returned va
Laurent Vivier wrote:
D> This allows an error to be reported to the caller of qdev_device_add()
>
> Signed-off-by: Laurent Vivier
Reviewed-by: Juan Quintela
Laurent Vivier wrote:
> Commit f3a850565693 ("qdev/qbus: add hidden device support") has
> introduced a generic way to hide a device but it has modified
> qdev_device_add() to check a specific option of the failover device,
> "failover_pair_id", before calling the generic mechanism.
>
> It's not n
Laurent Vivier wrote:
> We dont't need a flag to know if the primary device must be hidden, we
> can rely on the machine state:
> Device is hidden if the machine is in prelaunch state (src) or
> in inmigrate state with migration status set to none (dst).
> We don't need to check the flag in virtio
Laurent Vivier wrote:
> The intend of failover is to allow a VM with a VFIO networking card to
> be migrated without disrupting the network operation by switching
> to a virtio-net device during the migration.
>
> This simple change allows a simulated device like e1000e to be tested
> rather than
Hi
On Wed, Nov 18, 2020 at 8:33 PM Markus Armbruster wrote:
> marcandre.lur...@redhat.com writes:
>
> > From: Marc-André Lureau
> >
> > Since g_input_stream_read_all() may return less than requested when the
> > stream is malformed, we should treat this condition as a runtime user
> > error (g_
On Wed, 25 Aug 2021 11:39:39 -0300
Daniel Henrique Barboza wrote:
> The upcoming FORM2 NUMA affinity will support asymmetric NUMA topologies
> and doesn't need be concerned with all the legacy support for older
> pseries FORM1 guests.
>
> We're also not going to calculate associativity domains b
Stefan Reiter writes:
> From: Stefan Reiter
>
> The following sequence can produce a race condition that results in
> responses meant for different clients being sent to the wrong one:
>
> (QMP, no OOB)
> 1) client A connects
> 2) client A sends 'qmp_capabilities'
> 3) 'qmp_dispatch' runs in cor
The appended patch fixes the link to Wiki Windows page on Website
Download Sources page.
Furthermore I would like to propose to change the instructions for
Native builds with MSYS2 on Wiki Windows page.
Please remove the section which copies system binaries to match the
expected file names!
On Wed, 25 Aug 2021 11:39:40 -0300
Daniel Henrique Barboza wrote:
> The pSeries machine will support a new NUMA affinity form, FORM2.
> This new FORM will be negotiated via ibm,architecture-vec5 during
> CAS. All artifacts and assumptions that are currently on use for
> FORM1 affinity will be dep
The Zb[abcs] extensions have complete public review and are nearing
ratifications. These individual extensions are one part of what was
previously though of as the "BitManip" (B) extension, leaving the
final details of future Zb* extensions open as they will undergo
further public discourse.
Thi
For RV64, the shamt field in slli.uw is 6 bits wide. While the encoding
space currently reserves a wider shamt-field (for use is a future RV128
ISA), setting the additional bit to 1 will not map to slli.uw for RV64
and needs to be treated as an illegal instruction.
Note that this encoding being re
The following instructions are part of Zbs:
- b{set,clr,ext,inv}
- b{set,clr,ext,inv}i
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- The changes to the Zbs instructions (i.e. the REQUIRE_ZBS macro) and
its use for qualifying the Zb
The bitmanipulation ISA extensions will be ratified as individual
small extension packages instead of a large B-extension. The first
new instructions through the door (these have completed public review)
are Zb[abcs].
This adds new 'x-zba', 'x-zbb', 'x-zbc' and 'x-zbs' properties for
these in tar
The following instructions are part of Zba:
- add.uw (RV64 only)
- sh[123]add (RV32 and RV64)
- sh[123]add.uw (RV64-only)
- slli.uw (RV64-only)
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- The changes to the Zba instructions (i.e.
Zbs 1.0.0 (just as the 0.93 draft-B before) does no provide for W-form
instructions for Zbs (single-bit instructions). Remove them.
Note that these instructions had already been removed for the 0.93
version of the draft-B extenstion and have not been present in the
binutils patches circulating in
The following instructions are part of Zbc:
- clmul
- clmulh
- clmulr
Note that these instructions were already defined in the pre-0.93 and
the 0.93 draft-B proposals, but had not been omitted in the earlier
addition of draft-B to QEmu.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Hend
The 1.0.0 version of Zbb does not contain pack/packu/packh. However, a
zext.h instruction is provided (built on pack/packh from pre-0.93
draft-B) is available.
This commit adds zext.h and removes the pack* instructions.
Note that the encodings for zext.h are different between RV32 and
RV64, which
The Zb[abcs] ratification package does not include the proposed
shift-one instructions. There currently is no clear plan to whether
these (or variants of them) will be ratified as Zbo (or a different
extension) or what the timeframe for such a decision could be.
Signed-off-by: Philipp Tomsich
Rev
This reassigns the instructions that are part of Zbb into it, with the
notable exceptions of the instructions (rev8, zext.w and orc.b) that
changed due to gorci, grevi and pack not being part of Zb[abcs].
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
C
With everything classified as Zb[abcs] and pre-0.93 draft-B
instructions that are not part of Zb[abcs] removed, we can remove the
remaining support code for RVB.
Note that RVB has been retired for good and misa.B will neither mean
'some' or 'all of' Zb*:
https://lists.riscv.org/g/tech-bitmanip/m
The bitmanipulation ISA extensions will be ratified as individual
small extension packages instead of a large B-extension. The first
new instructions through the door (these have completed public review)
are Zb[abcs].
This adds new 'x-zba', 'x-zbb', 'x-zbc' and 'x-zbs' properties for
these in tar
With the addition of Zb[abcs], we also need to add disassembler
support for these new instructions.
Signed-off-by: Philipp Tomsich
---
(no changes since v2)
Changes in v2:
- Fix missing ';' from last-minute whitespace cleanups.
disas/riscv.c | 157
With the changes to Zb[abcs], there's some encodings that are
different in RV64 and RV32 (e.g., for rev8 and zext.h). For these,
we'll need a helper macro allowing us to select on RV32, as well.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in
The following instructions are part of Zbs:
- b{set,clr,ext,inv}
- b{set,clr,ext,inv}i
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- The changes to the Zbs instructions (i.e. the REQUIRE_ZBS macro) and
its use for qualifying the Zb
Zbs 1.0.0 (just as the 0.93 draft-B before) does no provide for W-form
instructions for Zbs (single-bit instructions). Remove them.
Note that these instructions had already been removed for the 0.93
version of the draft-B extenstion and have not been present in the
binutils patches circulating in
The 1.0.0 version of Zbb does not contain grev/grevi. Instead, a
rev8 instruction (equivalent to the rev8 pseudo-instruction built on
grevi from pre-0.93 draft-B) is available.
This commit adds the new rev8 instruction and removes grev/grevi.
Note that there is no W-form of this instruction (bot
The following instructions are part of Zbc:
- clmul
- clmulh
- clmulr
Note that these instructions were already defined in the pre-0.93 and
the 0.93 draft-B proposals, but had not been omitted in the earlier
addition of draft-B to QEmu.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Hend
The following instructions are part of Zba:
- add.uw (RV64 only)
- sh[123]add (RV32 and RV64)
- sh[123]add.uw (RV64-only)
- slli.uw (RV64-only)
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in v3:
- The changes to the Zba instructions (i.e.
Resent as a v6 with this change and a bug-fix for orc.b.
This now again passes all of SPEC 2017 w/ a compiler that makes good use of
the Zb[abcs] instructions, including orc.b for string-functions.
On Wed, 25 Aug 2021 at 15:40, Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 8/23/21
For RV64, the shamt field in slli.uw is 6 bits wide. While the encoding
space currently reserves a wider shamt-field (for use is a future RV128
ISA), setting the additional bit to 1 will not map to slli.uw for RV64
and needs to be treated as an illegal instruction.
Note that this encoding being re
The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
orc.b instruction (equivalent to the orc.b pseudo-instruction built on
gorci from pre-0.93 draft-B) is available, mainly targeting
string-processing workloads.
This commit adds the new orc.b instruction and removed gorc/gorci.
Sign
This reassigns the instructions that are part of Zbb into it, with the
notable exceptions of the instructions (rev8, zext.w and orc.b) that
changed due to gorci, grevi and pack not being part of Zb[abcs].
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
C
The Zb[abcs] extensions have complete public review and are nearing
ratifications. These individual extensions are one part of what was
previously though of as the "BitManip" (B) extension, leaving the
final details of future Zb* extensions open as they will undergo
further public discourse.
Thi
The 1.0.0 version of Zbb does not contain grev/grevi. Instead, a
rev8 instruction (equivalent to the rev8 pseudo-instruction built on
grevi from pre-0.93 draft-B) is available.
This commit adds the new rev8 instruction and removes grev/grevi.
Note that there is no W-form of this instruction (bot
The Zb[abcs] ratification package does not include the proposed
shift-one instructions. There currently is no clear plan to whether
these (or variants of them) will be ratified as Zbo (or a different
extension) or what the timeframe for such a decision could be.
Signed-off-by: Philipp Tomsich
Rev
The 1.0.0 version of Zbb does not contain pack/packu/packh. However, a
zext.h instruction is provided (built on pack/packh from pre-0.93
draft-B) is available.
This commit adds zext.h and removes the pack* instructions.
Note that the encodings for zext.h are different between RV32 and
RV64, which
With the changes to Zb[abcs], there's some encodings that are
different in RV64 and RV32 (e.g., for rev8 and zext.h). For these,
we'll need a helper macro allowing us to select on RV32, as well.
Signed-off-by: Philipp Tomsich
Reviewed-by: Richard Henderson
---
(no changes since v3)
Changes in
With everything classified as Zb[abcs] and pre-0.93 draft-B
instructions that are not part of Zb[abcs] removed, we can remove the
remaining support code for RVB.
Note that RVB has been retired for good and misa.B will neither mean
'some' or 'all of' Zb*:
https://lists.riscv.org/g/tech-bitmanip/m
With the addition of Zb[abcs], we also need to add disassembler
support for these new instructions.
Signed-off-by: Philipp Tomsich
---
(no changes since v2)
Changes in v2:
- Fix missing ';' from last-minute whitespace cleanups.
disas/riscv.c | 157
The 1.0.0 version of Zbb does not contain gorc/gorci. Instead, a
orc.b instruction (equivalent to the orc.b pseudo-instruction built on
gorci from pre-0.93 draft-B) is available, mainly targeting
string-processing workloads.
This commit adds the new orc.b instruction and removed gorc/gorci.
Sign
Le 25/08/2021 à 16:21, Thomas Huth a écrit :
> Since we are not using Launchpad anymore, there is no more need for
> this script.
>
> Signed-off-by: Thomas Huth
> ---
> scripts/show-fixed-bugs.sh | 91 --
> 1 file changed, 91 deletions(-)
> delete mode 100755
Make 'qemu-img commit' work on Windows.
Command 'commit' requires reopening backing file in RW mode. So,
add reopen prepare/commit/abort handlers and change dwShareMode
for CreateFile call in order to allow further read/write reopening.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/418
(2021-08-25 10:25:12 +0100)
>
> are available in the Git repository at:
>
> https://git.linaro.org/people/pmaydell/qemu-arm.git
> tags/pull-target-arm-20210825
>
> for you to fetch changes up to 24b1a6aa43615be22c7ee66bd68ec5675f6a6a9a:
>
> docs: Document how t
On Wed, 25 Aug 2021 at 14:28, Philippe Mathieu-Daudé wrote:
>
> On 8/25/21 2:43 PM, marcandre.lur...@redhat.com wrote:
> > From: Marc-André Lureau
> >
> > DTC is widely available, we could consider to stop bundling it.
> >
> > curl -s 'https://repology.org/api/v1/project/dtc' | \
> >jq -r 'g
Hi,
Yes - to make the bpf() syscall capabilities are required, which libvirt
have no intentions to give.
Does it make any sense to leave syscall if mmap works?
On Fri, Aug 20, 2021 at 6:34 AM Jason Wang wrote:
>
> 在 2021/7/13 下午11:37, Andrew Melnychenko 写道:
> > -static bool ebpf_rss_set_indirect
Hi,
> I wonder if it's better to use separated properties instead of implying
> an order here?
>
Not really, technically RSS BPF interface may be changed (it's already
changed after RFC).
And libvirt should use something unified, so it's better to use fd array.
If any changes occur - those changes
Hi,
> I wonder if this can be done as helper for TAP/bridge.
>
Well, it does already, libvirt may create TAP device and pass it in command
line or using getfd qmp command.
E.g it's the qemu to launch those helper with set-uid.
>
Then libvirt won't even need to care about that?
Yea, we may think
Hi,
Yes, the stamp check was added.
So the qemu emulator should return a suitable RSS BPF helper or nothing.
Each qemu emulator may have a different helper that suits it.
So, the idea is to ask for the helper from qemu.
On Tue, Aug 24, 2021 at 9:41 AM Markus Armbruster wrote:
> Andrew Melnichenk
On Tue, Aug 24, 2021 at 1:52 PM Philippe Mathieu-Daudé wrote:
>
>
> Aren't Nascent uC based on 8051? Because AFAIK QEMU doesn't emulate
> this architecture.
I am trying to emulate the TI MSP430 microcontroller.
-Gautam.
On Wed, Aug 25, 2021 at 02:59:06PM +0400, Marc-André Lureau wrote:
> > For HMP, this is a bit trickier, since at least 'set_password' already
> > has the 'connected' parameter following the mandatory 'password' one, so
> > we need to prefix the display ID with "id=" to allow correct parsing.
> >
>
On Wed, Aug 25, 2021 at 01:26:09PM +0200, Stefan Reiter wrote:
> > It's not something done with other commands afaik, feels a bit awkward (the
> > "connected = display"...).
> >
>
> Indeed, if there is a better way I'd love to use it.
>
> One idea I had was making the parameter 'connected' OR 'd
On Fri, Jul 23, 2021 at 05:38:06PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jul 23, 2021 at 06:18:55PM +0200, Kevin Wolf wrote:
> > Am 23.07.2021 um 12:33 hat Richard W.M. Jones geschrieben:
> > > Under SELinux, Unix domain sockets have two labels. One is on the
> > > disk and can be set with co
On Wed, 25 Aug 2021 at 20:03, Gautam Bhat wrote:
> I am trying to emulate the TI MSP430 microcontroller.
The MSP430 is a custom 16-bit architecture. We don't have an
emulation of that kind of CPU. If you're mostly doing this to look
at how QEMU's device emulation is implemented, you should probab
The following changes since commit d42685765653ec155fdf60910662f8830bdb2cef:
Open 6.2 development tree (2021-08-25 10:25:12 +0100)
are available in the Git repository at:
https://gitlab.com/ehabkost/qemu.git tags/x86-next-pull-request
for you to fetch changes up to f429dbf8fc526a9cacf531176
From: Yang Zhong
The AVX_VNNI feature is not in Cooperlake platform, remove it
from cpu model.
Signed-off-by: Yang Zhong
Message-Id: <20210820054611.84303-1-yang.zh...@intel.com>
Fixes: c1826ea6a052 ("i386/cpu: Expose AVX_VNNI instruction to guest")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Edu
From: Chenyi Qiang
At present, there's no mechanism intelligent enough to virtualize split
lock detection correctly. Remove it in Snowridge CPU model to avoid the
feature exposure.
Signed-off-by: Chenyi Qiang
Message-Id: <20210630012053.10098-1-chenyi.qi...@intel.com>
Signed-off-by: Eduardo Hab
Hi
On Wed, Aug 25, 2021 at 10:13 PM Peter Maydell
wrote:
> On Wed, 25 Aug 2021 at 14:28, Philippe Mathieu-Daudé
> wrote:
> >
> > On 8/25/21 2:43 PM, marcandre.lur...@redhat.com wrote:
> > > From: Marc-André Lureau
> > >
> > > DTC is widely available, we could consider to stop bundling it.
> >
On Wed, 25 Aug 2021 at 20:55, Marc-André Lureau
wrote:
> fdt_check_full was added in 1.4.7:
> https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tag/?h=v1.4.7
>
> Only ubuntu appears to be lagging a bit behind. I wonder if they would
> consider an update.
I doubt it. You would need to wait until t
On Wed, 25 Aug 2021 at 12:00, Thomas Huth wrote:
>
> Hi Peter!
>
> The following changes since commit f9baca549e44791be0dd98de15add3d8452a8af0:
>
> Update version for v6.1.0 release (2021-08-24 17:59:52 +0100)
>
> are available in the Git repository at:
>
> https://gitlab.com/thuth/qemu.git t
Do not intent to access the vring MemoryRegion cache if
the queue is not ready (no vring available).
This fixes issue #301:
qemu-system-i386: include/exec/memory_ldst_cached.h.inc:77: void
address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint16_t, MemTxAttrs,
MemTxResult *):
Asserti
Hi
On Thu, Aug 26, 2021 at 12:00 AM Peter Maydell
wrote:
> On Wed, 25 Aug 2021 at 20:55, Marc-André Lureau
> wrote:
> > fdt_check_full was added in 1.4.7:
> > https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tag/?h=v1.4.7
> >
> > Only ubuntu appears to be lagging a bit behind. I wonder if they
On Wed, Aug 25, 2021 at 12:48:35PM +, Luis Fernando Fujita Pires wrote:
> From: David Gibson
> > Hrm.. I'm a bit concerned about mkaing this a more widespread function,
> > because it has a nasty edge case... which is basically unavoidable in an
> > abs64()
> > implementation. Specifically:
On 8/25/21 10:09 PM, Philippe Mathieu-Daudé wrote:
> Do not intent to access the vring MemoryRegion cache if
> the queue is not ready (no vring available).
>
> This fixes issue #301:
>
> qemu-system-i386: include/exec/memory_ldst_cached.h.inc:77: void
> address_space_stw_le_cached(MemoryRegion
From: Eduardo Habkost
> > Right, that's true of any standard implementation of abs().
> > I thought about making it return uint64_t, but that could make it
> > weird for other uses of abs64(), where callers wouldn't expect a type
> > change from int64_t to uint64_t. Maybe create a separate uabs64
On Wed, Aug 25, 2021 at 02:59:37PM +0800, Xiaoyao Li wrote:
> Hi Eduardo,
>
> I have some question regrading Intel PT live migration.
>
> Commit "e37a5c7fa459 (i386: Add Intel Processor Trace feature support)"
> expose Intel PT with a fixed capabilities of CPUID 0x14 for live migration.
> And the
On Wed, Aug 25, 2021 at 11:36:08AM +0400, Marc-André Lureau wrote:
> Shouldn't this be placed earlier in the function, before
> runstate_is_running() and vm_stop() ?
Good point... Will respin, thanks!
--
Peter Xu
On Wed, Aug 25, 2021 at 08:37:17PM +, Luis Fernando Fujita Pires wrote:
> From: Eduardo Habkost
>
> > > Right, that's true of any standard implementation of abs().
> > > I thought about making it return uint64_t, but that could make it
> > > weird for other uses of abs64(), where callers woul
On 8/25/21 11:18 PM, Eduardo Habkost wrote:
> On Wed, Aug 25, 2021 at 08:37:17PM +, Luis Fernando Fujita Pires wrote:
>> From: Eduardo Habkost
>>
Right, that's true of any standard implementation of abs().
I thought about making it return uint64_t, but that could make it
weird f
Markus,
On Wed, Aug 25, 2021 at 09:54:12AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > Both dump-guest-memory and live migration have vm state cached internally.
> > Allowing them to happen together means the vm state can be messed up.
> > Simply
> > block live migration for dump-
201 - 300 of 319 matches
Mail list logo
