Re: [Qemu-devel] How address_space_rw works?

Re: [Qemu-devel] How address_space_rw works?

[Kaiyuan]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

> > Where is the code location that I can set breakpoint to observe the fast path for R/W requests to RAM?
> 
> Nowhere really, because the fast path is done directly in assembly code
> that TCG generates at run-time.
> 
> > Whether dose Qemu provide method to disable fast path so that I can set one breakpoint to catch all requests both MMIO and RAM?
> 
> You can modify the backends (e.g. tcg/i386/tcg-target.c) to do this, but
> chances are that there is a better way to do it.The request address I get from backends is host virtual address. But, only guest physical address is useful to me.> 
> What are you trying to do?Thanks for your answer. I need to implement a checker that locates logically between bus and memory.  This checker will catch all access requests, check if the address of requests are in a table I maintain. If address is in table, checker will forwards request to memory. If address is not in table, request will be discarded. You can think it as a firewall for addresses of R/W access requests.C code should be simple, a if black can do it. But difficulty for me is to find a location in source where can catch requests and get address of R/W to put code. Could you provide any suggestions? Thank you very much.-Kaiyuan Liang
 



[-- Attachment #2: Type: text/html, Size: 1423 bytes --]

Re: [Qemu-devel] How address_space_rw works?

[Paolo Bonzini]

On 10/04/2015 09:47, Kaiyuan wrote:
>>> Where is the code location that I can set breakpoint to observe
>>> the fast path for R/W requests to RAM?
>> 
>> Nowhere really, because the fast path is done directly in assembly
>> code that TCG generates at run-time.
>> 
>>> Whether dose Qemu provide method to disable fast path so that I
>>> can set one breakpoint to catch all requests both MMIO and RAM?
>> 
>> You can modify the backends (e.g. tcg/i386/tcg-target.c) to do
>> this, but chances are that there is a better way to do it.
> 
> The request address I get from backends is host virtual address. But,
> only guest physical address is useful to me.

The backends are passed guest virtual addresses for the qemu_ld and
qemu_st TCG opcodes.

>> What are you trying to do?
> 
> Thanks for your answer. I need to implement a checker that locates
> logically between bus and memory.  This checker will catch all access
> requests, check if the address of requests are in a table I maintain.
> If address is in table, checker will forwards request to memory. If
> address is not in table, request will be discarded. You can think it
> as a firewall for addresses of R/W access requests.

If that's the case, you could also add your check to
memory_region_section_get_iotlb.  Search for PHYS_SECTION_WATCH,
watch_mem_ops and io_mem_watch, and do the same for your new special
case.  This is where QEMU decides between using the slow path or the
fast path.

However this will not catch instruction fetches.  How to do that depends
on the details of what you are doing.  In particular, if you need to
trap on _all_ instruction fetches and not just the first, it's likely
that QEMU is not the best project to base your changes on.  A simulator
would be more appropriate.

Paolo

Re: [Qemu-devel] How address_space_rw works?

[Kaiyuan]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

> If that's the case, you could also add your check to
> memory_region_section_get_iotlb.  Search for PHYS_SECTION_WATCH,
> watch_mem_ops and io_mem_watch, and do the same for your new special
> case.  This is where QEMU decides between using the slow path or the
> fast path.
> 
> However this will not catch instruction fetches.  How to do that depends
> on the details of what you are doing.  In particular, if you need to
> trap on _all_ instruction fetches and not just the first, it's likely
> that QEMU is not the best project to base your changes on.  A simulator
> would be more appropriate.
> 
Hi, Paolo. I need more time to review and debug relevant code. It will be a time-consuming process. I appreciate your suggestions. Thank you very much.
-Kaiyuan Liang



[-- Attachment #2: Type: text/html, Size: 869 bytes --]

Re: [Qemu-devel] How address_space_rw works?

[Paolo Bonzini]

On 10/04/2015 06:47, Kaiyuan wrote:
>> That's because we have a fast-path for RAM accesses that directs
>> them to the bit of host memory we're using as guest RAM:
>>  * for KVM, the guest gets the host memory directly mapped and
>>    accesses it without trapping out to userspace
>>  * for TCG, our TLB data structure caches the guest-virtual-address
>>    to host-virtual-address mapping, and the generated TCG code
>>    does a fast inline lookup in this cache; if it hits then it
>>    can load or store to the host memory without ever having to
>>    come out to a C helper function
> 
> Thanks for your explanation about fast path. I am reviewing and debugging code related to TCG.
> 
> Where is the code location that I can set breakpoint to observe the fast path for R/W requests to RAM?

Nowhere really, because the fast path is done directly in assembly code
that TCG generates at run-time.

> Whether dose Qemu provide method to disable fast path so that I can set one breakpoint to catch all requests both MMIO and RAM?

You can modify the backends (e.g. tcg/i386/tcg-target.c) to do this, but
chances are that there is a better way to do it.

What are you trying to do?

Paolo

Re: [Qemu-devel] How address_space_rw works?

[Kaiyuan]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

> That's because we have a fast-path for RAM accesses that directs
> them to the bit of host memory we're using as guest RAM:
>  * for KVM, the guest gets the host memory directly mapped and
>    accesses it without trapping out to userspace
>  * for TCG, our TLB data structure caches the guest-virtual-address
>    to host-virtual-address mapping, and the generated TCG code
>    does a fast inline lookup in this cache; if it hits then it
>    can load or store to the host memory without ever having to
>    come out to a C helper functionThanks for your explanation about fast path. I am reviewing and debugging code related to TCG.Where is the code location that I can set breakpoint to observe the fast path for R/W requests to RAM?Whether dose Qemu provide method to disable fast path so that I can set one breakpoint to catch all requests both MMIO and RAM?
> address_space_rw is one of the functions used in the slow path,
> which is taken for IO accesses, or for other corner cases like
> accessing memory with a debug watchpoint set. Note that not
> all accesses go through it; there are other ways to access the
> address space including the ldl_phys() functions, and TCG
> slow-path accesses go directly to io_mem_read/write because
> they've already dealt with the RAM case.
By debugging Qemu, I see call stack trace that io_writeb/io_readb ->... -> io_mem_read/write ->... -> address_space_rw. Can I catch all MMIO access requests by setting single breakpoint in io_writeeb or io_readb? Thank you very much.
-Kaiyuan Liang



[-- Attachment #2: Type: text/html, Size: 1909 bytes --]

Re: [Qemu-devel] How address_space_rw works?

[Peter Maydell]

On 9 April 2015 at 09:34, Kaiyuan <kaiyuanl@tju.edu.cn> wrote:
> Hello, guys
>
> In my understanding, function exec.c:address_space_rw is used to handle read
> and write access requests to address space. In order to check my opinion, I
> write guest code and debug Qemu to see the path of code execution.
>
> If I read or write with address of MMIO like UART,  it will hit function
> address_space_rw.
>
> *UART_ADDR = 'c';  //hit address_space_rw
>
> However, if I read from or write to RAM address, it does NOT hit
> address_space_rw.

That's because we have a fast-path for RAM accesses that directs
them to the bit of host memory we're using as guest RAM:
 * for KVM, the guest gets the host memory directly mapped and
   accesses it without trapping out to userspace
 * for TCG, our TLB data structure caches the guest-virtual-address
   to host-virtual-address mapping, and the generated TCG code
   does a fast inline lookup in this cache; if it hits then it
   can load or store to the host memory without ever having to
   come out to a C helper function

address_space_rw is one of the functions used in the slow path,
which is taken for IO accesses, or for other corner cases like
accessing memory with a debug watchpoint set. Note that not
all accesses go through it; there are other ways to access the
address space including the ldl_phys() functions, and TCG
slow-path accesses go directly to io_mem_read/write because
they've already dealt with the RAM case.

-- PMM

[Qemu-devel] How address_space_rw works?

[Kaiyuan]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

Hello, guys


In my understanding, function exec.c:address_space_rw is used to handle read and write access requests to address space. In order to check my opinion, I write guest code and debug Qemu to see the path of code execution.


If I read or write with address of MMIO like UART,  it will hit function address_space_rw.


*UART_ADDR = 'c';  //hit address_space_rw


However, if I read from or write to RAM address, it does NOT hit address_space_rw. Consider below code:


char str[] = {'h', 'e', 'l', 'l', 'o', '\0'};   //This array should locate in RAM virtualized by Qemu
char temp = str[2]; //Read char from RAM, NO hit to address_space_rw
str[3] = 'k';  //Write char to RAM, NO hit to address_space_rw


For address_space_rw, why access requests to MMIO and RAM address have different results? Are there any other functions that are used to handle R/W request to virtual RAM in Qemu?


Could you give me some idea? Any suggestions will be helpful. Thanks a lot.




-Kaiyuan 






[-- Attachment #2: Type: text/html, Size: 1753 bytes --]