[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC qom-cpu 04/41] cpu: Introduce CPUClass::set_

From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH RFC qom-cpu 04/41] cpu: Introduce CPUClass::set_pc() for gdb_set_cpu_pc()
Date: Mon, 01 Jul 2013 12:03:52 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

On 07/01/2013 10:25 AM, Andreas Färber wrote:
> This is the first case where I am proposing the use of uint64_t in place
> of target_ulong. In this case a gdb command using such a hook is not
> performance-sensitive. Do you see this as an acceptable path for adding
> further CPUClass hooks such as MMU fault handling?

I think that would be appropriate.  MMU faulting can't be much more performance
sensitive than device emulation, which is already standardizing on 64-bit

> Should we introduce some ulong-target-max typedef similar to hwaddr or
> use plain uint64_t as done here?

I would think hwaddr wouldn't be appropriate, since that's supposed to be
talking about physical addresses, and that's not the case here.  The name (and
admittedly minimal documentation for) ram_addr_t sounds right, but it seems to
be sized wrong, so I don't know what it's actually supposed to be.

Unless someone has a better suggestion, I'd stay with uint64_t.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]