On 25/09/20 22:46, Ashish Kalra wrote: > I was also considering abstracting this vendor/SEV specific debug > interface via the CPUClass object, the CPUClass object aleady has cpu > specific methods for doing things like guest VA to GPA translations like the > get_phys_page_attrs_debug() method and it will be a simple and clean > approach to override this method with a SEV specific > get_phys_page_attrs_debug() if SEV guest is active and SEV debug policy > is allowed. [...] > > I can probably add new interfaces/methods to this CPUClass object for > guest memory read/writes for debugging purpose and then invoke the same > from the generic cpu_memory_rw_debug() interface. > > Let me know your thougts on abstracting this debug interface via the > CPUClass object ? > > Or the other option is to introduce the new MemoryDebugOps you described > above and additionally apply SEV/SEV-ES considerations in CPUClass > methods such as gdb_read_register, gdb_write_register, etc.
Yes, this makes the most sense, however you're right that you don't need translate in MemoryDebugOps. I don't think read/write should be moved to CPUClass, however, since you can use a MemTxAttr to tell the read/write MemoryDebugOps whether the page is encrypted or not. Paolo
