Avi Kivity wrote:
> Jan Kiszka wrote:
>> This is not a hack (it shouldn't have been merged upstream otherwise):
>> cpu_physical_memory_write_rom() takes system-wide physical addresses
>> while kvm_patch_opcode_byte() works with per-CPU linear addresses.
>>
>
> From exec.c:
>
>> /* virtual memory access for debug */
>> int cpu_memory_rw_debug(CPUState *env, target_ulong addr,
>> uint8_t *buf, int len, int is_write)
>> {
>> int l;
>> target_phys_addr_t phys_addr;
>> target_ulong page;
>>
>> while (len > 0) {
>> page = addr & TARGET_PAGE_MASK;
>> phys_addr = cpu_get_phys_page_debug(env, page);
>> /* if no physical page mapped, return an error */
>> if (phys_addr == -1)
>> return -1;
>> l = (page + TARGET_PAGE_SIZE) - addr;
>> if (l > len)
>> l = len;
>> cpu_physical_memory_rw(phys_addr + (addr & ~TARGET_PAGE_MASK),
>> buf, l, is_write);
>> len -= l;
>> buf += l;
>> addr += l;
>> }
>> return 0;
>> }
>
> I'm talking about replacing cpu_physical_memory_rw() with
> cpu_physical_memory_write_rom() (for the write case).
Ah, miss-read your point.
> Is there a case
> where the debugger should be prevented from writing into ROM? If so,
> maybe cpu_memory_rw_debug_rom() for breakpoints?
Good and valid question. So far only the 'M' gdb packet uses
cpu_physical_memory_rw in write mode, and I don't know if there is any
reason to deny modifying ROM code that way. Hmm, will check with
upstream and change there first. So forget about this patch for now.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
