On 2023/12/22 22:45, Alex Bennée wrote:
Akihiko Odaki writes:
On 2023/12/21 19:38, Alex Bennée wrote:
We can only request a list of registers once the vCPU has been
initialised so the user needs to use either call the get function on
vCPU initialisation or during the translation phase.
We don
Steven Sistare writes:
> On 12/22/2023 7:20 AM, Markus Armbruster wrote:
>> Steve Sistare writes:
>>
>>> Currently, a vm in the suspended state is not completely stopped. The VCPUs
>>> have been paused, but the cpu clock still runs, and runstate notifiers for
>>> the transition to stopped have
On Fri, Dec 22, 2023 at 11:18 PM Michael Tokarev wrote:
>
> From: Elen Avan
> Signed-off-by: Elen Avan
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2051
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2050
> Fixes: a200d53b1fde "virtio-gpu: replace PIXMAN for region/rect t
01.12.2023 17:25, Kevin Wolf :
Kevin Wolf (3):
block: Fix crash when loading snapshot on inactive node
vl: Improve error message for conflicting -incoming and -loadvm
iotests: Basic tests for internal snapshots
This smells like a stable-8.2 material, at least the first change
(tho I'd
From: Elen Avan
Signed-off-by: Elen Avan
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2051
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2050
Fixes: a200d53b1fde "virtio-gpu: replace PIXMAN for region/rect test"
Cc: qemu-sta...@nongnu.org
Reviewed-by: Michael Tokarev
---
in
Hi Yajun,
Sorry for the late reply.
Apart from the few nitpicks commented, I think it is valid to start
from this series and then add the capability to re-send the
configuration in case the source changes it by another series on top.
That would allow us to keep both series small.
Not sure if all
On Mon, Sep 18, 2023 at 6:51 AM Yajun Wu wrote:
>
> Register a new vmstate for virtio-net with an early_setup flag to send
> the device state during migration setup.
>
> This can reduce the migration downtime of a virtio-net device with a
> vhost-user backend.
>
> This feature is disabled by defau
On Mon, Sep 18, 2023 at 6:56 AM Yajun Wu wrote:
>
> Add New API vhost_dev_start_presetup to notify backend the start
> and end of presetup.
>
> API vhost_dev_presetup to send out the device configurations:
> 1. acked_features
> 2. memory table
> 3. vring information
> 4. disable host/guest notifie
On 12/22/2023 7:37 AM, Markus Armbruster wrote:
"Annie.li" writes:
Hi Markus,
On 12/5/2023 3:34 PM, Markus Armbruster wrote:
You neglected to cc: QAPI schema maintainers. I found it by chance.
Next time :)
Yep, should have cc to the maintainers.
Annie Li writes:
Following hmp/qmp com
Extract the code into new functions, and swap T0/T1 so that T0 corresponds
to the first immediate in the instruction stream.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/translate.c | 90 -
1 file changed, 50 insertions(+), 40 deletions(-)
diff --git a/ta
X86_SPECIAL_ZExtOp0 and X86_SPECIAL_ZExtOp2 are poorly named; they are a hack
that is needed by scalar insertion and extraction instructions, and not really
related to zero extension: for PEXTR the zero extension is done by the
generation
functions, for PINSR the high bits are not used at all and
gen_lea_v_seg (called by gen_add_A0_ds_seg) already zeroes any
bits of s->A0 beyond s->aflag. It does so before summing the
segment base and, if not in 64-bit mode, also after summing it.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/emit.c.inc | 4 +---
target/i386/tcg/translate.c | 2 --
decode->mem is only used if one operand has has_ea == true. String
operations will not use decode->mem and will load A0 on their own, because
they are the only case of two memory operands in a single instruction.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/decode-new.c.inc | 20 ++-
The previous check erroneously allowed CMP to be modified with LOCK.
Instead, tag explicitly the instructions that do support LOCK.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/decode-new.c.inc | 17 ++---
target/i386/tcg/decode-new.h | 3 +++
target/i386/tcg/emit.c.inc
The new decoder likes to compute the address in A0 very early, so the
gen_lea_v_seg in gen_pop_T0 would clobber the address of the memory
operand. Instead use T0 since it is already available and will be
overwritten immediately after.
Reviewed-by: Richard Henderson
Signed-off-by: Paolo Bonzini
Just create a temporary for the occasion.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/translate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index b79c312465b..afe0fa6c65f 100644
--- a/target/i386/tcg/transla
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/decode-new.c.inc | 12
1 file changed, 12 insertions(+)
diff --git a/target/i386/tcg/decode-new.c.inc b/target/i386/tcg/decode-new.c.inc
index 2bdbb1bba0f..232c6a45c96 100644
--- a/target/i386/tcg/decode-new.c.inc
+++ b/target/i386/tc
Create a new temporary, to ease the register allocator's work.
Creation of the temporary is pushed into gen_ext_tl, which
also allows NULL as the first parameter now.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/translate.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
dif
The new decoder would rather have the operand in T0 when expanding SCAS, rather
than use R_EAX directly as gen_scas currently does. This makes SCAS more
similar
to CMP and SUB, in that CC_DST = T0 - T1.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/translate.c | 45 -
cpu_cc_compute_all() has an argument that is always equal to CC_OP for
historical
reasons (dating back to commit a7812ae4123, "TCG variable type checking.",
2008-11-17,
which added the argument to helper_cc_compute_all). It does not make sense for
the
argumnt to have any other value, so remove
Use _tl operations for 32-bit operands on 32-bit targets, and only go
through trunc and extu ops for 64-bit targets. While the trunc/ext
ops should be pretty much free after optimization, the optimizer also
does not like having the same temporary used in multiple EBBs.
Therefore it is nicer to not
The main difficulty here is that a page fault when writing to the destination
must not overwrite the flags. Therefore, the compute-flags helper must be
called with a temporary destination instead of using gen_jcc1*.
For simplicity, I am using an unconditional cmpxchg operation, that becomes
a NOP
The new x86 decoder wants the gen_* functions to compute EFLAGS before
writeback, which can be an issue for instructions with a memory
destination such as ARPL or shifts.
Extract code to compute the EFLAGS without clobbering CC_SRC, in case
the memory write causes a fault. The flags writeback mec
Usually the registers are just moved into s->T0 without much care for
their operand size. However, in some cases we can get more efficient
code if the operand fetching logic syncs with the emission function
on what is nicer.
All the current uses are mostly demonstrative and only reduce the code
i
Similar to gen_setcc1, make gen_cmovcc1 receive TCGv. This is more friendly
to simultaneous implementation in the old and the new decoder.
A small wart is that s->T0 of CMOV is currently the *second* argument (which
would ordinarily be in T1). Therefore, the condition has to be inverted in
order
Do not use gen_op, and pull the load from the accumulator into
disas_insn.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/translate.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index edbad0ad746..c7d480
is_int is always 1, and error_code is always zero.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/excp_helper.c | 7 +++
target/i386/tcg/helper-tcg.h | 3 +--
target/i386/tcg/misc_helper.c | 2 +-
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/target/i386/tcg/excp_helper.c
Take advantage of the fact that there can be no 1 bits between SF and OF.
If they were adjacent, you could sum SF and get a carry only if SF was
already set. Then the value of OF in the sum is the XOR of OF itself,
the carry (which is SF) and 0 (the value of the OF bit in the addend):
this is OF^S
gen_jcc() has been changed to accept a relative offset since the
new decoder was written. Adjust the J operand, which is meant
to be used with jump instructions such as gen_jcc(), to not
include the program counter and to not truncate the result, as
both operations are now performed by common code
The main things here are a bunch of cleanups to the common logic of
the new decoder, some changes to translate.c that prepare for redoing
one-byte opcodes in the new framework, and the implementation of the
CMPccXADD instruction that is new in Sierra Forest processors.
These are all relatively inn
ALU instructions can write to both memory and flags. If the CC_SRC*
and CC_DST locations have been written already when a memory access
causes a fault, the value in CC_SRC* and CC_DST might be interpreted
with the wrong CC_OP (the one that is in effect before the instruction.
Besides just using t
OF is equal to the carry flag, so use the same CCPrepare.
Signed-off-by: Paolo Bonzini
---
target/i386/tcg/translate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index 8fb80011a22..a16eb8d4008 100644
--- a/target/i386/tcg/tran
The address translation logic in get_physical_address() will currently
truncate physical addresses to 32 bits unless long mode is enabled.
This is incorrect when using physical address extensions (PAE) outside
of long mode, with the result that a 32-bit operating system using PAE
to access memory a
MSR_VM_HSAVE_PA bits 0-11 are reserved, as are the bits above the
maximum physical address width of the processor. Setting them to
1 causes a #GP (see "15.30.4 VM_HSAVE_PA MSR" in the AMD manual).
The same is true of VMCB addresses passed to VMRUN/VMLOAD/VMSAVE,
even though the manual is not clea
CR3 bits 63:32 are ignored in 32-bit mode (either legacy 2-level
paging or PAE paging). Do this in mmu_translate() to remove
the last where get_physical_address() meaningfully drops the high
bits of the address.
Cc: qemu-sta...@nongnu.org
Suggested-by: Richard Henderson
Fixes: 4a1e9d4d11c ("targ
The A20 mask is only applied to the final memory access. Nested
page tables are always walked with the raw guest-physical address.
Unlike the previous patch, in this one the masking must be kept, but
it was done too early.
Cc: qemu-sta...@nongnu.org
Fixes: 4a1e9d4d11c ("target/i386: Use atomic o
If ptw_translate() does a MMU_PHYS_IDX access, the A20 mask is already
applied in get_physical_address(), which is called via probe_access_full()
and x86_cpu_tlb_fill().
If ptw_translate() on the other hand does a MMU_NESTED_IDX access,
the A20 mask must not be applied to the address that is looke
The address translation logic in get_physical_address() will currently
truncate physical addresses to 32 bits unless long mode is enabled.
This is incorrect when using physical address extensions (PAE) outside
of long mode, with the result that a 32-bit operating system using PAE
to access memory a
Hi Richard,
Thanks for the suggestion.
If it's ok to consume another bit(3 bits total) for Pointer Masking flags,
I'll do it.
>so that the translator can see the true width of the address
I guess I'll need a helper to calculate the exact number of bits to
shift(0, 7 or 16) based on those 2 extract
On Mon, Sep 18, 2023 at 6:51 AM Yajun Wu wrote:
>
> Define new virtio device vmstate for early save/load (happens in
> LM setup stage). Same as original vmstate, except:
>
> In LM setup phase of the destination VM, the guest memory has not
> been synchronized yet. To address this, a flag has been
On Fri, Dec 22, 2023 at 5:16 PM Paolo Bonzini wrote:
>
> On Fri, Dec 22, 2023 at 10:04 AM Paolo Bonzini wrote:
> > > If the extension is not needed, then the a20 mask isn't either.
> >
> > I think it is. The extension is not needed because the masking is
> > applied by either TCG (e.g. in gen_lea
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/9.0 for any
user-visible changes.
signature.asc
Description: PGP signature
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/9.0 for any
user-visible changes.
signature.asc
Description: PGP signature
On Fri, Dec 22, 2023 at 10:04 AM Paolo Bonzini wrote:
> > If the extension is not needed, then the a20 mask isn't either.
>
> I think it is. The extension is not needed because the masking is
> applied by either TCG (e.g. in gen_lea_v_seg_dest or gen_add_A0_im) or
> mmu_translate(); but the a20 ma
On 12/22/2023 7:20 AM, Markus Armbruster wrote:
> Steve Sistare writes:
>
>> Currently, a vm in the suspended state is not completely stopped. The VCPUs
>> have been paused, but the cpu clock still runs, and runstate notifiers for
>> the transition to stopped have not been called. This causes p
Sure. of course. I'll do that next week. While v3 would be a single patch
that only contains the first commit.
Thanks,
Yong
On Fri, Dec 22, 2023 at 5:54 PM Markus Armbruster wrote:
> Hyman Huang writes:
>
> > This patch allows to display feature and status bits in
> > virtio-status.
> >
> > Ap
Hi, this patch fixes a bug: https://gitlab.com/qemu-project/qemu/-/issues/2051
From: Elen Avan
Date: Fri, 22 Dec 2023 14:39:48 +
Subject: [RFC] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2051
Signed-off-by: Elen Avan
---
include/ui/rect.h | 2 +-
1 file changed, 1 insertio
Hi Peter,
> On 18 Dec 2023, at 10:32, Peter Maydell wrote:
>
> This patchset adds support for emulating the Arm architectural features
> FEAT_NV and FEAT_NV2 which allow nested virtualization, i.e. where a
> hypervisor can run a guest which thinks it is running at EL2.
>
> Nominally FEAT_NV is
Hi,
It seems that we still need the kernel KVM side to be sorted out first [1],
so I believe we should wait a bit until we can review this RFC. Otherwise we
might risk reviewing something that has to be changed later.
[1] https://lore.kernel.org/kvm/20231221095002.7404-1-duc...@eswincomputing.c
From: Mark Cave-Ayland
Add a dummy register at address 0x6000 in the MMIO memory region to allow the
initial diagnostic test to timeout rather than getting stuck in a loop
continuously writing "en_write: tx not ready" to the console.
Signed-off-by: Mark Cave-Ayland
Tested-by: Thomas Huth
Messa
From: Mark Cave-Ayland
The old QEMU memory accessors used in the original NextCube patch series had
separate functions for 1, 2 and 4 byte accessors. When the series was finally
merged a simple wrapper function was written to dispatch the memory accesses
using the original functions.
Convert scr
From: Mark Cave-Ayland
The old QEMU memory accessors used in the original NextCube patch series had
separate functions for 1, 2 and 4 byte accessors. When the series was finally
merged a simple wrapper function was written to dispatch the memory accesses
using the original functions.
Convert mmi
The following changes since commit 191710c221f65b1542f6ea7fa4d30dde6e134fd7:
Merge tag 'pull-request-2023-12-20' of https://gitlab.com/thuth/qemu into
staging (2023-12-20 09:40:16 -0500)
are available in the Git repository at:
https://gitlab.com/huth/qemu.git tags/m68k-pull-2023-12-22
for
From: Mark Cave-Ayland
Rename dma_ops to next_dma_ops and the read/write functions to next_dma_read()
and next_dma_write() respectively, mark next_dma_ops as DEVICE_BIG_ENDIAN and
also improve the consistency of the val variable in next_dma_read() and
next_dma_write().
Signed-off-by: Mark Cave-A
From: Mark Cave-Ayland
These static memory regions are contained within the machine and do not need to
be dynamically allocated.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Thomas Huth
Message-ID: <20231220131641.592826-12-mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Thomas Huth
---
hw/m68
From: Mark Cave-Ayland
Move the old_scr2 variable to NeXTPC so that the old SCR2 register state is
stored along with the current SCR2 state.
Since the SCR2 register is 32-bits wide, convert old_scr2 to uint32_t and
update the SCR2 register access code to allow unaligned writes.
Note that this i
From: Mark Cave-Ayland
Ensure that the LED status is updated by calling next_scr2_led_update() whenever
the SC2 register is written.
Signed-off-by: Mark Cave-Ayland
Reviewed-by: Thomas Huth
Message-ID: <20231220131641.592826-10-mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Thomas Huth
---
hw
From: Mark Cave-Ayland
The state of the led is stored in the SCR2 register which is part of the NeXTPC
device.
Note that this is a migration break for the NeXTPC device, but as nothing will
currently boot then we simply bump the migration version for now.
Signed-off-by: Mark Cave-Ayland
Review
From: Mark Cave-Ayland
The phase variable represents part of the state machine used to clock data out
of the NextRtc device.
Note that this is a migration break for the NeXTRtc struct, but as nothing will
currently boot then we simply bump the migration version for now.
Signed-off-by: Mark Cave
From: Mark Cave-Ayland
These are now redundant with the scr2 and old_scr2 fields in NeXTPC. Rename
the function from nextscr2_write() to next_scr2_rtc_update() to better
reflect its purpose. At the same time replace the manual bit manipulation with
the extract32() and deposit32() functions.
Sign
From: Mark Cave-Ayland
Normally a DMA FLUSH command is used to ensure that data is completely written
to the device and/or memory, so remove the pulse of the SCSI DMA IRQ if a DMA
FLUSH command is received. This enables the NeXT ROM monitor to start to load
from a SCSI disk.
Signed-off-by: Mark
Akihiko Odaki writes:
> On 2023/12/21 19:38, Alex Bennée wrote:
>> We can only request a list of registers once the vCPU has been
>> initialised so the user needs to use either call the get function on
>> vCPU initialisation or during the translation phase.
>> We don't expose the reg number to th
On Fri, Dec 22, 2023 at 11:14:12AM +0800, Xiaoyao Li wrote:
> On 12/21/2023 7:05 PM, Daniel P. Berrangé wrote:
> > On Wed, Nov 15, 2023 at 02:15:01AM -0500, Xiaoyao Li wrote:
> > > From: Isaku Yamahata
> > >
> > > For GetQuote, delegate a request to Quote Generation Service.
> > > Add property "q
Something odd is going on here.
Your cover letter and PATCH 4 arrived here with
Content-Type: text/plain; charset=UTF-8
Good.
PATCH 2:
Content-Type: text/plain; charset="US-ASCII"; x-default=true
PATCH 1 and 3:
Content-Type: text/plain; charset=N
git-am chokes on that:
erro
Steven Sistare writes:
> FYI for Markus and Blake. No change since V6 and V7.
I accidentally replied to v6 instead of here. Sorry for the
inconvenience!
"Annie.li" writes:
> Hi Markus,
>
> On 12/5/2023 3:34 PM, Markus Armbruster wrote:
>> You neglected to cc: QAPI schema maintainers. I found it by chance.
>> Next time :)
> Yep, should have cc to the maintainers.
>>
>> Annie Li writes:
>>
>>> Following hmp/qmp commands are implemented for pressi
writes:
> From: Ankit Agrawal
>
> NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
> partitioning of the GPU device resources (including device memory) into
> several (upto 8) isolated instances. Each of the partitioned memory needs
> a dedicated NUMA node to operate. The
After adding a KVM finalize() implementation, turn cbom_blocksize into a
class property. Follow the same design we used with 'vlen' and 'elen'.
The duplicated 'cbom_blocksize' KVM property can be removed from
kvm_riscv_add_cpu_user_properties().
Signed-off-by: Daniel Henrique Barboza
---
target
Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it
that forbids 'pmp' to be changed in vendor CPUs, like we did with the
'mmu' option.
We'll also have to manually set 'pmp = true' to generic CPUs that were
still relying on the previous default to set it.
Signed-off-by: Daniel He
Turning 'vlen' into a class property will allow its default value to be
overwritten by cpu_init() later on, solving the issue we have now where
CPU specific settings are getting overwritten by the default.
For 'vlen', 'elen' and the blocksize options we need a way of tracking
if the user set a val
Every property in riscv_cpu_options[] will be migrated to
riscv_cpu_properties[]. This will make their default values init
earlier, allowing cpu_init() functions to overwrite them. We'll also
implement common getters and setters that both accelerators will use,
allowing them to share validations th
'priv_spec' and 'vext_spec' are two string options used as a fancy way
of setting integers in the CPU state (cpu->env.priv_ver and
cpu->env.vext_ver). It requires us to deal with string parsing and to
store them in cpu_cfg.
We must support these string options, but we don't need to store them.
We
We'll use this function in target/riscv/cpu.c to implement setters that
won't allow vendor CPU options to be changed.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 5 +
target/riscv/cpu.h | 1 +
target/riscv/tcg/tcg-cpu.c | 5 -
3 files changed, 6 insert
Keep all class properties in riscv_cpu_properties[].
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 110 +++--
1 file changed, 57 insertions(+), 53 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 613e8d5ddc..d2400f
Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from
riscv_cpu_init()") already did some of the work by making some
cpu_init() functions to explictly enable their own 'mmu' default.
The generic CPUs didn't get update by that commit, so they are still
relying on the defaults set by the 'm
Keep all class properties in riscv_cpu_properties[].
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 68 --
1 file changed, 36 insertions(+), 32 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 260932e117..613e8d
Do the same we did with 'cbom_blocksize' in the previous patch.
Remove the now unused kvm_cpu_set_cbomz_blksize() setter.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 45 +-
target/riscv/kvm/kvm-cpu.c | 28
The same rework did in 'priv_spec' is done for 'vext_spec'. This time is
simpler, since we only accept one value ("v1.0") and we'll always have
env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to
convert string to 'vext_ver' back and forth like we needed for
'priv_spec'.
Signed
Keep all class properties in riscv_cpu_properties[].
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 69 +-
1 file changed, 37 insertions(+), 32 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 7b1cc5d0c9..260932
They aren't being used.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu_cfg.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/target/riscv/cpu_cfg.h b/target/riscv/cpu_cfg.h
index f4605fb190..c67a8731d3 100644
--- a/target/riscv/cpu_cfg.h
+++ b/target/riscv/cpu_cfg.h
@@ -136,8 +
To turn cbom_blocksize and cboz_blocksize into class properties we need
KVM specific changes.
KVM is creating its own version of these options with a customized
setter() that prevents users from picking an invalid value during init()
time. This comes at the cost of duplicating each option that KVM
Hi,
This new version fixes all instances of 'const PropertyInfo' added,
changing it to 'static const PropertyInfo', like suggested by Richard in
v1.
Patches based on Alistair's riscv-to-apply.next. Series is also found
here:
https://gitlab.com/danielhb/qemu/-/tree/fix_cpu_opts_v2
Changes from v
Do the same thing we did with 'vlen' in the previous patch with 'elen'.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 52 --
target/riscv/tcg/tcg-cpu.c | 5
2 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/target/
The array is empty and can be removed.
Signed-off-by: Daniel Henrique Barboza
---
target/riscv/cpu.c | 5 -
target/riscv/cpu.h | 1 -
target/riscv/kvm/kvm-cpu.c | 9 -
target/riscv/tcg/tcg-cpu.c | 4
4 files changed, 19 deletions(-)
diff --git a/target/riscv/cpu
Steve Sistare writes:
> Currently, a vm in the suspended state is not completely stopped. The VCPUs
> have been paused, but the cpu clock still runs, and runstate notifiers for
> the transition to stopped have not been called. This causes problems for
> live migration. Stale cpu timers_state i
On 12/22/23 01:40, Richard Henderson wrote:
On 12/22/23 04:51, Daniel Henrique Barboza wrote:
+const PropertyInfo prop_cbom_blksize = {
static? Same for cboz in the next patch.
Same in every other patch where I added a PropertyInfo it seems.
I'll fix it in v2. Thanks,
Daniel
r~
To enable accelerated VirtIO GPUs for the guest we need the rendering
support on the host but currently it's not reported in the
configuration summary. Add a graphics backend section and report the
status of the VirGL and Rutabaga support libraries.
Signed-off-by: Alex Bennée
---
meson.build | 6
Fabiano Rosas writes:
> Add the direct-io migration parameter that tells the migration code to
> use O_DIRECT when opening the migration stream file whenever possible.
Why is that useful?
> This is currently only used with fixed-ram migration for the multifd
> channels that transfer the RAM pag
On 12/22/23 11:09, Eric Auger wrote:
Hi Cédric,
On 12/21/23 22:23, Cédric Le Goater wrote:
On 12/21/23 18:14, Eric Auger wrote:
Hi Cédric,
On 12/21/23 17:00, Cédric Le Goater wrote:
[ ... ]
+static void iommufd_backend_init(Object *obj)
+{
+ IOMMUFDBackend *be = IOMMUFD_BACKEND(obj);
+
Fabiano Rosas writes:
> Add a new migration capability 'fixed-ram'.
>
> The core of the feature is to ensure that each RAM page has a specific
> offset in the resulting migration stream. The reasons why we'd want
> such behavior are:
>
> - The resulting file will have a bounded size, since pages
Alberto Garcia writes:
> This allows returning a tree of all object properties under a given
> path, in a way similar to scripts/qmp/qom-tree.
Use case? We already have that script, and also HMP info qom-tree.
> Signed-off-by: Alberto Garcia
> ---
> qapi/qom.json | 10 +-
> qom/
Philippe Mathieu-Daudé writes:
> Hi,
>
> I just did an audit of QDev properties from different
> models sharing the same name, but of different types
> (as of v8.2.0-rc1).
>
> Nothing wrong, but some having the same meaning could
> use the same type :)
Yes.
> Just sharing:
>
> ---
>2 addr
>
Hi guys,
Is there a way for a client-side driver to know if a VirGL command
fails? The function virgl_renderer_submit_cmd() does return an error if
one of the commands fail, but virgl_cmd_submit_3d() ignores the return
code. It looks like VIRTIO_GPU_CMD_SUBMIT_3D would return a success,
even
Hi Cédric,
On 12/21/23 22:23, Cédric Le Goater wrote:
> On 12/21/23 18:14, Eric Auger wrote:
>> Hi Cédric,
>>
>> On 12/21/23 17:00, Cédric Le Goater wrote:
>>> [ ... ]
>>>
>>>
+static void iommufd_backend_init(Object *obj)
+{
+ IOMMUFDBackend *be = IOMMUFD_BACKEND(obj);
+
>>
Commit c2118e9e1ab ("configure: don't try a "native" cross for linux-user",
2023-11-23) sought to avoid issues with using the native compiler with a
cross-endian or cross-bitness setup. However, in doing so it ended up
requiring a cross compiler setup (and most likely a slow compiler setup)
even w
Hyman Huang writes:
> This patch allows to display feature and status bits in
> virtio-status.
>
> Applications could find it helpful to compare status and features
> that are numeric encoded. For example, an upper application could
> use the features (encoded as a number) in the output of "ovs-v
v2:
* PATCH 1 superseded by commit 95a40c44501 (dump: Add close fd on
error return to avoid resource leak)
* PATCH 2 fell through the cracks; reposting unchanged
Markus Armbruster (1):
dump: Fix HMP dump-guest-memory -z without -R
dump/dump-hmp-cmds.c | 2 +-
1 file changed, 1 insertion(+),
-z without -R has no effect: the dump format remains @elf. Fix the
logic error so it becomes @kdump-zlib.
Fixes: e6549197f7ed (dump: Add command interface for kdump-raw formats)
Fixes: CID 1523841
Signed-off-by: Markus Armbruster
Reviewed-by: Stephen Brennan
Reviewed-by: Marc-André Lureau
---
QE tested this series v4 with regression tests. It has fixed the qemu
core issues that hit last time.And everything works fine.
Tested-by: Lei Yang
On Fri, Dec 22, 2023 at 1:43 AM Eugenio Pérez wrote:
>
> It will hold properties shared among all vhost_vdpa instances associated
> with of the
On Wed, Nov 08, 2023 at 11:20:08PM -0800, Xin Li wrote:
> Date: Wed, 8 Nov 2023 23:20:08 -0800
> From: Xin Li
> Subject: [PATCH v3 2/6] target/i386: mark CR4.FRED not reserved
> X-Mailer: git-send-email 2.42.0
>
> The CR4.FRED bit, i.e., CR4[32], is no longer a reserved bit when FRED
> is expose
1 - 100 of 110 matches
Mail list logo
