On Tue, Dec 01, 2020 at 02:38:30PM +, Peter Maydell wrote:
> On Tue, 1 Dec 2020 at 14:28, Ashish Kalra wrote:
> > On Tue, Dec 01, 2020 at 11:48:23AM +, Peter Maydell wrote:
> > > This seems like a weird place to insert these hooks. Not
> > > all debug related accesses are going to go via
On Tue, Dec 01, 2020 at 11:48:23AM +, Peter Maydell wrote:
> On Mon, 16 Nov 2020 at 19:07, Ashish Kalra wrote:
> >
> > From: Ashish Kalra
> >
> > Introduce new MemoryDebugOps which hook into guest virtual and physical
> > memory debug interfaces such as cpu_memory_rw_debug, to allow vendor
On Tue, 1 Dec 2020 at 14:28, Ashish Kalra wrote:
> On Tue, Dec 01, 2020 at 11:48:23AM +, Peter Maydell wrote:
> > This seems like a weird place to insert these hooks. Not
> > all debug related accesses are going to go via
> > cpu_memory_rw_debug(). For instance when the gdb stub is in
> >
On Mon, 16 Nov 2020 at 19:07, Ashish Kalra wrote:
>
> From: Ashish Kalra
>
> Introduce new MemoryDebugOps which hook into guest virtual and physical
> memory debug interfaces such as cpu_memory_rw_debug, to allow vendor specific
> assist/hooks for debugging and delegating accessing the guest
* Ashish Kalra (ashish.ka...@amd.com) wrote:
> From: Ashish Kalra
>
> Introduce new MemoryDebugOps which hook into guest virtual and physical
> memory debug interfaces such as cpu_memory_rw_debug, to allow vendor specific
> assist/hooks for debugging and delegating accessing the guest memory.
>
From: Ashish Kalra
Introduce new MemoryDebugOps which hook into guest virtual and physical
memory debug interfaces such as cpu_memory_rw_debug, to allow vendor specific
assist/hooks for debugging and delegating accessing the guest memory.
This is required for example in case of AMD SEV platform
