On 1/30/18 4:37 PM, Edgar E. Iglesias wrote:
> On Tue, Jan 30, 2018 at 04:34:37PM -0600, Brijesh Singh wrote:
>>
>> On 1/30/18 3:59 PM, Edgar E. Iglesias wrote:
>>> On Mon, Jan 29, 2018 at 11:41:11AM -0600, Brijesh Singh wrote:
Currently, the guest memory access for the debug purpose is perf
On Tue, Jan 30, 2018 at 04:34:37PM -0600, Brijesh Singh wrote:
>
>
> On 1/30/18 3:59 PM, Edgar E. Iglesias wrote:
> > On Mon, Jan 29, 2018 at 11:41:11AM -0600, Brijesh Singh wrote:
> >> Currently, the guest memory access for the debug purpose is performed
> >> using the memcpy(). Lets extend the
On 1/30/18 3:59 PM, Edgar E. Iglesias wrote:
> On Mon, Jan 29, 2018 at 11:41:11AM -0600, Brijesh Singh wrote:
>> Currently, the guest memory access for the debug purpose is performed
>> using the memcpy(). Lets extend the 'struct MemoryRegion' to include
>> ram_debug_ops callbacks. The ram_debug_
On Mon, Jan 29, 2018 at 11:41:11AM -0600, Brijesh Singh wrote:
> Currently, the guest memory access for the debug purpose is performed
> using the memcpy(). Lets extend the 'struct MemoryRegion' to include
> ram_debug_ops callbacks. The ram_debug_ops can be used to override
> memcpy() with somethin
Currently, the guest memory access for the debug purpose is performed
using the memcpy(). Lets extend the 'struct MemoryRegion' to include
ram_debug_ops callbacks. The ram_debug_ops can be used to override
memcpy() with something else.
The feature can be used by encrypted guest -- which can regist
