This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/249
** Changed in: qemu
Status: Confirmed => Expired
**
The QEMU code implementing the iret insn is still doing loads/stores as
if kernel mode, so this is still a bug.
** Changed in: qemu
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
The QEMU project is currently considering to move its bug tracking to
another system. For this we need to know which bugs are still valid
and which could be closed already. Thus we are setting older bugs to
"Incomplete" now.
If you still think this bug report here is valid, then please switch
the
The change should only be dynamically visible when doing an iretq from
and to the same protection level, AFAICT. The code clearly[sic] works
now for the interrupt return that is used by the linux kernel,
presumably {from=kernel, to=kernel} or {from=kernel, to=user}. I would
claim that to make
Robert, please try replacing s/_kernel_/_data_/g.
That will use the current address space and permissions as opposed to
cpl=0 address space and permissions.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
That function is for "do a guest memory load as if from the kernel" (ie
with the permissions and page table settings that guest kernel-mode
accesses would use). We'd need to look at what the required semantics
for the instruction are for user-mode iretq: are the loads supposed to
be done with only
Peter: I think your intuition is right. The POPQ_RA (pop quad, passing
through return address handle) is only called from helper_ret_protected,
and it suspiciously calls cpu_ldq_kernel_ra which calls
cpu_mmu_index_kernel which only is prepared for kernel space iretq (and
of course the substring
I've stepped/nexted from the helper_iret_protected, going deep into the
bowels of the TLB, MMU and page table engine. None of which I
understand. The helper_ret_protected faults in the first POPQ_RA. I'll
investigate the value of sp at the time of the POPQ_RA.
Here's the POPQ_RA in
Thanks, that's pretty clear. I expect you'll find the bug is just that
QEMU doesn't get the semantics of an iret from userspace correct. The
helper_iret_protected() function is probably a good place to look.
--
You received this bug notification because you are a member of qemu-
devel-ml, which
yes, it is intentional. I don't yet understand why, but am talking to
those who do.
https://github.com/dotnet/runtime/blob/1b02665be501b695b9c22c1ebd69148c07a225f6/src/coreclr/src/pal/src/arch/amd64/context2.S#L183
--
You received this bug notification because you are a member of qemu-
Is dotnet intentionally doing an iret? It seems like an odd thing for a
userspace program to do, given it's basically "return from interrupt".
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1866892
I have confirmed that the dotnet guest application is executing a
"iretq" instruction when this guest kernel bug is hit. A first round of
analysis shows nothing unreasonable at the point the iretq is executed.
The $rsp points into the middle of a mapped in page, the returned-to
$rip looks
A simpler case seems to produce the same error. See
https://bugs.launchpad.net/qemu/+bug/1824344
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1866892
Title:
guest OS catches a page fault bug
13 matches
Mail list logo
