On Tue, Dec 01, 2020 at 12:08:28PM +0000, Peter Maydell wrote: > On Mon, 16 Nov 2020 at 19:19, Ashish Kalra <Ashish.Kalra@xxxxxxx> wrote: > > > > From: Brijesh Singh <brijesh.singh@xxxxxxx> > > > > From: Brijesh Singh <brijesh.singh@xxxxxxx> > > > > Currently, guest memory access for debugging purposes is performed using > > memcpy(). Extend the 'struct MemoryRegion' to include new callbacks that > > can be used to override the use of memcpy() with something else. > > > > The new callbacks can be used to display the guest memory of an SEV guest > > by registering callbacks to the SEV memory encryption/decryption APIs. > > > > Typical usage: > > > > mem_read(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs); > > mem_write(uint8_t *dst, uint8_t *src, uint32_t len, MemTxAttrs *attrs); > > We already have a function prototype for "I need to call a function > to do this read or write": > MemTxResult (*read_with_attrs)(void *opaque, > hwaddr addr, > uint64_t *data, > unsigned size, > MemTxAttrs attrs); > MemTxResult (*write_with_attrs)(void *opaque, > hwaddr addr, > uint64_t data, > unsigned size, > MemTxAttrs attrs); > > Do the prototypes for accessing guest RAM that needs decryption > really need to be different from that? > This again falls back to the same thought process, to keep the debug specific code separate from the generic code. If the above MemoryRegionOps are used, then again we are using generic code to invoke debug specific stuff. Thanks, Ashish
