I have only skimmed the diffs. Your knowledge of the deep semantics,
gained by close differential reading of intel and amd docs, is truly
amazing. Many thanks for pushing this through!
I have 2 nits, perhaps stylistic only.
For code like "sp -= 2" or "sp += 2" followed or preceded by a write to
e any of this chatter in this email thread on the bug report
https://gitlab.com/qemu-project/qemu/-/issues/249
Robert Henry
On Sat, Jun 15, 2024 at 4:25 PM Richard Henderson <
richard.hender...@linaro.org> wrote:
> On 6/11/24 09:20, Robert R. Henry wrote:
> > This fixes a bug wher
I have not done anything on this front, alas.
From: Aaron Lindsay
Sent: Thursday, March 24, 2022 1:17 PM
To: qemu-devel@nongnu.org ; qemu-...@nongnu.org
Cc: Alex Bennée ; richard.hender...@linaro.org
; Robert Henry
Subject: [EXTERNAL] Plugins Not Reporting
: Sunday, September 19, 2021 10:54 AM
To: rrh.henry ; qemu-disc...@nongnu.org
Cc: Alex Bennée ; qemu-devel
Subject: [EXTERNAL] Re: Range of vcpu_index to plugin callbacks
(Cc'ing qemu-devel@ mailing list since this is a development question).
On 9/19/21 19:44, Robert Henry wrote:
> What is t
maintainers:
>>
>> ./scripts/get_maintainer.pl -f target/i386/fpu_helper.c
>> Paolo Bonzini (maintainer:X86 TCG CPUs)
>> Richard Henderson (maintainer:X86 TCG CPUs)
>> Eduardo Habkost (maintainer:X86 TCG CPUs)
>>
>> On 6/1/20 1:22 AM, Robert Henry
The newish test 'basic gdbstub support' fails for me on an out-of-the-box
build on a host x86_64. (See below for the config.log head.)
Is this failure expected? If so, where can I see that in the various CI
engines you have running them?
In digging through the test driver python code in
tes
in the SSE_HELPER_B macro which takes a
MMXREG which is an MMREG_UNION which does not provide, to the extent that I can
figure this out, a handle to bits 79:64 of the aliased-with x87 register.
I find it hard to believe that an apparent bug like this has been here
"forever". Am I mi
Background: The ia-32/ia-64 fxsave64 instruction saves fp80 or legacy SSE mmx
registers. The mmx registers are saved as if they were fp80 values. The lower
64 bits of the constructed fp80 value is the mmx register. The upper 16 bits
of the constructed fp80 value are reserved; see the last row o
n be used to subvert some aspects of the GPL.
I don't understand the details of this concern, nor know where the "line in the
sand" is.
Robert Henry
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 this
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 _k
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 i386/seg_help
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-
devel-ml,
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 reasonabl
This appears to be similar to
https://bugs.launchpad.net/qemu/+bug/1866892 (and much simpler)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824344
Title:
x86: retf or iret pagefault sets wrong err
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 whe
Public bug reported:
The linux guest OS catches a page fault bug when running the dotnet
application.
host = metal = x86_64
host OS = ubuntu 19.10
qemu emulation, without KVM, with "tiny code generator" tcg; no plugins; built
from head/master
guest emulation = x86_64
guest OS = ubuntu 19.10
gues
I run git blame in the capstone repository, and cs_free has been around
for at least 4 years in the capstone ABI. I can not tell if the need to
call cs_free is a (new) requirement. Documentation capstone is a little
informal...
--
You received this bug notification because you are a member of qem
or 3 days on
qemu+plugins and only observed a tolerable growth in qemu's memory consumption.
From: Alex Bennée
Sent: Friday, January 24, 2020 11:44 AM
To: Robert Henry
Cc: Laurent Desnogues ; qemu-devel@nongnu.org
Subject: Re: [EXTERNAL] Re: QEMU for aarch
, my problems went away.
I think this lack of persistence of insn should be documented, or treated as a
bug to be fixed.
From: Alex Bennée
Sent: Friday, January 24, 2020 8:36 AM
To: Robert Henry
Cc: qemu-devel@nongnu.org
Subject: [EXTERNAL] Re: QEMU for aarch64
I wrote a QEMU plugin for aarch64 where the insn and mem callbacks print out
the specifics of the guest instructions as they are "executed". I expect this
trace stream to be well behaved but it is not. By well-behaved, I expect memory
insns print out some memory details, non-memory insns don't
Public bug reported:
Looking at origin/master head, the function cap_disas_plugin leaks
memory.
per capstone's examples using their ABI, cs_free(insn, count); needs to
called just before cs_close.
I discovered this running qemu under valgrind.
** Affects: qemu
Importance: Undecided
I don't understand what
unsigned int qemu_plugin_mem_size_shift(qemu_plugin_meminfo_t info);
does. The documentation in qemu-plugin.h is silent on this matter. It
appears to expose more of the guts of qemu that I don't yet know.
The documentation on the new plugin capabilities of qemu is silent about the
order call back registration should be done, and is also silent on the order in
which call backs are fired.
Case in point: The callback registered by qemu_plugin_register_vcpu_mem_cb is
called after the call back regis
24 matches
Mail list logo
