This patchset fixes hard-coded maximum priority of interrupt priority
register and also changes this register to WARL field to align the PLIC
spec.
Changelog:
v3:
* fix opposite of power-of-2 max priority checking expression.
v2:
* change interrupt priority register to WARL field.
Jim Shu
PLIC spec [1] requires interrupt source priority registers are WARL
field and the number of supported priority is power-of-2 to simplify SW
discovery.
Existing QEMU RISC-V machine (e.g. shakti_c) don't strictly follow PLIC
spec, whose number of supported priority is not power-of-2. Just change
The maximum priority level is hard-coded when writing to interrupt
priority register. However, when writing to priority threshold register,
the maximum priority level is from num_priorities Property which is
configured by platform.
Also change interrupt priority register to use num_priorities
Hi Clément,
> > > @@ -180,7 +180,15 @@ static void sifive_plic_write(void *opaque, hwaddr
> > > addr, uint64_t value,
> > > if (addr_between(addr, plic->priority_base, plic->num_sources << 2))
> > > {
> > > uint32_t irq = ((addr - plic->priority_base) >> 2) + 1;
> > >
> > > -
HACK ahead.
There are devices that require the guest to be stopped to tell us what
is the size of its state. So we need to stop the vm "before" we
cal the functions.
It is a hack because:
- we are "starting" the guest again to stop it in migration_complete()
I know, I know, but it is not
Signed-off-by: Juan Quintela
---
migration/migration.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 97fefd579e..35e512887a 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@
So remove it everywhere.
Signed-off-by: Juan Quintela
---
include/migration/register.h | 6 ++
migration/savevm.h | 2 +-
hw/s390x/s390-stattrib.c | 2 +-
hw/vfio/migration.c| 6 ++
migration/block-dirty-bitmap.c | 5 ++---
migration/block.c
We split the function into to:
- state_pending_estimate: We estimate the remaining state size without
stopping the machine.
- state pending_exact: We calculate the exact amount of remaining
state.
The only "device" that implements different functions for _estimate()
and _exact() is ram.
And it appears that what is wrong is the code. During bulk stage we
need to make sure that some block is dirty, but no games with
max_size at all.
Signed-off-by: Juan Quintela
---
migration/block.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/migration/block.c
Until previous commit, save_live_pending() was used for ram. Now with
the split into state_pending_estimate() and state_pending_exact() it
is not needed anymore, so remove them.
Signed-off-by: Juan Quintela
---
include/migration/register.h | 7 +++
migration/savevm.h | 6
It was only used for RAM, and in that case, it means that this amount
of data was sent for memory. Just delete the field in all callers.
Signed-off-by: Juan Quintela
---
include/migration/register.h | 20 ++--
migration/savevm.h | 4 +---
hw/s390x/s390-stattrib.c
Hi
VFIO migration has several requirements:
- the size of the state is only known when the guest is stopped
- they need to send possible lots of data.
this series only address the 1st set of problems.
What they do:
- res_compatible parameter was not used anywhere, just add that information to
Hi Alex,
On Mon, Sep 26, 2022, at 6:46 AM, Alex Bennée wrote:
> Please confirm this is the correct mapping for you.
it's the correct mapping, thanks for adding it! (... & sorry for the multi-day
latency!)
Reviewed-by: Simon Safar
>
> Signed-off-by: Alex Bennée
> Cc: Simon Safar
> ---
>
Hi Paolo,
On Sun, Sep 25, 2022 at 9:07 AM Bin Meng wrote:
>
> Hi Paolo,
>
> On Tue, Sep 13, 2022 at 5:52 PM Marc-André Lureau
> wrote:
> >
> > Hi
> >
> > On Wed, Aug 24, 2022 at 12:52 PM Bin Meng wrote:
> >>
> >> From: Bin Meng
> >>
> >> The maximum number of wait objects for win32 should be
On Thu, 29 Sep 2022 12:16:48 PDT (-0700), dgilb...@redhat.com wrote:
* Palmer Dabbelt (pal...@rivosinc.com) wrote:
Ztso, the RISC-V extension that provides the TSO memory model, was
recently frozen. This provides support for Ztso on targets that are
themselves TSO.
Signed-off-by: Palmer
Rather than recurse directly on mmu_translate, go through the
same softmmu lookup that we did for the page table walk.
This centralizes all knowledge of MMU_NESTED_IDX, with respect
to setup of TranslationParams, to get_physical_address.
Signed-off-by: Richard Henderson
---
Use probe_access_full in order to resolve to a host address,
which then lets us use a host cmpxchg to update the pte.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/279
Signed-off-by: Richard Henderson
---
target/i386/tcg/sysemu/excp_helper.c | 242 +++
1 file
Replace with PTE_HPHYS for the page table walk, and a direct call
to mmu_translate for the final stage2 translation. Hoist the check
for HF2_NPT_MASK out to get_physical_address, which avoids the
recursive call when stage2 is disabled.
We can now return all the way out to x86_cpu_tlb_fill before
Use a boolean to control the call to get_hphys instead
of passing a null function pointer.
Signed-off-by: Richard Henderson
---
target/i386/tcg/sysemu/excp_helper.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/target/i386/tcg/sysemu/excp_helper.c
These new mmu indexes will be helpful for improving
paging and code throughout the target.
Signed-off-by: Richard Henderson
---
target/i386/cpu-param.h | 2 +-
target/i386/cpu.h| 3 +
target/i386/tcg/sysemu/excp_helper.c | 82 ++--
Create TranslateParams for inputs, TranslateResults for successful
outputs, and TranslateFault for error outputs; return true on success.
Move stage1 error paths from handle_mmu_fault to x86_cpu_tlb_fill;
reorg the rest of handle_mmu_fault into get_physical_address.
Signed-off-by: Richard
Use atomic operations for pte updates, which is a long-standing
bug since our conversion to MTTCG. Modulo rebase, this has one
change from v1, which is the new patch 9.
r~
Based-on: 20220930212622.108363-1-richard.hender...@linaro.org
("[PATCH v6 00/18] tcg: CPUTLBEntryFull and
Use MMU_NESTED_IDX for each memory access, rather than
just a single translation to physical. Adjust svm_save_seg
and svm_load_seg to pass in mmu_idx.
This removes the last use of get_hphys so remove it.
Signed-off-by: Richard Henderson
---
target/i386/cpu.h| 2 -
We don't need one variable set per translation level,
which requires copying into pte/pte_addr for huge pages.
Standardize on pte/pte_addr for all levels.
Signed-off-by: Richard Henderson
---
target/i386/tcg/sysemu/excp_helper.c | 178 ++-
1 file changed, 91
Replace int is_write1 and magic numbers with the proper
MMUAccessType access_type and enumerators.
Signed-off-by: Richard Henderson
---
target/i386/tcg/sysemu/excp_helper.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git
Ping, or should I create a PR myself?
r~
On 9/1/22 07:15, Yoshinori Sato wrote:
On Thu, 01 Sep 2022 19:15:09 +0900,
Richard Henderson wrote:
The value previously chosen overlaps GUSA_MASK.
Rename all DELAY_SLOT_* and GUSA_* defines to emphasize
that they are included in TB_FLAGs. Add
On 10/2/22 07:52, BitFriends wrote:
my bad, then I was mislead by "Which is, in general, what you want for implementing a
custom instruction". Also the code around me is full of gen instructions, so I thought
that's what I should use.
So, when reading the doc I found out about the
thanks for the clarification, I will look at those insns. My instruction is
for some more advanced logging between guest and host, that should be done
quickly.
Regards
BitFriends
Peter Maydell schrieb am So., 2. Okt. 2022,
16:45:
> On Sun, 2 Oct 2022 at 10:22, BitFriends wrote:
> > I now
my bad, then I was mislead by "Which is, in general, what you want for
implementing a custom instruction". Also the code around me is full of gen
instructions, so I thought that's what I should use.
So, when reading the doc I found out about the cpu_{ld,st}*_mmu functions.
That sounds more what I
On Sun, 2 Oct 2022 at 10:22, BitFriends wrote:
> I now came up with this code:
>
> TCGv_i64 res = 0;
> TCGv_i64 addr = (TCGv_i64)(env->regs[R_EDI]);
>
> tcg_gen_qemu_ld_i64(res, addr, 0, MO_LEUQ);
>
> env->regs[R_EAX] = (target_ulong)res;
This is wrong, because you cannot read or write
On 10/2/22 02:20, BitFriends wrote:
I now came up with this code:
TCGv_i64 res = 0;
TCGv_i64 addr = (TCGv_i64)(env->regs[R_EDI]);
tcg_gen_qemu_ld_i64(res, addr, 0, MO_LEUQ);
env->regs[R_EAX] = (target_ulong)res;
However this crashes afterwards in test_bit. Maybe this is caused by an invalid
BitFriends writes:
> Hello,
>
> I am trying to create a custom instruction that accesses guest memory
> specified by an address in a register. I specifically
> want to read from that address. So I tried to do that using
> "tcg_gen_qemu_ld_i64(, env->regs[R_EDI], 0,
> MO_LEUQ);", but that
On Sun, Oct 02, 2022 at 11:59:42AM +0300, Maxim Levitsky wrote:
> On Thu, 2022-09-29 at 19:35 +0200, Paolo Bonzini wrote:
> > On 9/29/22 18:39, Christoph Hellwig wrote:
> > > On Thu, Sep 29, 2022 at 10:37:22AM -0600, Keith Busch wrote:
> > > > > I am aware, and I've submitted the fix to qemu here:
Hi
On Fri, Sep 30, 2022 at 11:49 PM Christian Schoenebeck
wrote:
>
> On Donnerstag, 29. September 2022 18:32:37 CEST Marc-André Lureau wrote:
> > From: Marc-André Lureau
> >
> > If slirp is not found during compile-time, and not manually disabled,
> > print a friendly error message, as
Rather than poking directly into RAM, add the bootinfo block as a proper
ROM, so that it's restored when rebooting the system. This way, if the
guest corrupts any of the bootinfo items, but then tries to reboot,
it'll still be restored back to normal as expected. This assumes the
bootinfo block
Hi Kevin,
On Fri, Sep 30, 2022 at 6:13 PM Kevin Wolf wrote:
>
> Am 28.09.2022 um 16:41 hat Bin Meng geschrieben:
> > From: Bin Meng
> >
> > At present there are two callers of get_tmp_filename() and they are
> > inconsistent.
> >
> > One does:
> >
> > /* TODO: extra byte is a hack to ensure
I now came up with this code:
TCGv_i64 res = 0;
TCGv_i64 addr = (TCGv_i64)(env->regs[R_EDI]);
tcg_gen_qemu_ld_i64(res, addr, 0, MO_LEUQ);
env->regs[R_EAX] = (target_ulong)res;
However this crashes afterwards in test_bit. Maybe this is caused by an
invalid access? Anything wrong about the code?
On Thu, 2022-09-29 at 19:35 +0200, Paolo Bonzini wrote:
> On 9/29/22 18:39, Christoph Hellwig wrote:
> > On Thu, Sep 29, 2022 at 10:37:22AM -0600, Keith Busch wrote:
> > > > I am aware, and I've submitted the fix to qemu here:
> > > >
> > > >
38 matches
Mail list logo
