SEV guest debugging support for Qemu

[Ashish Kalra <ashish.kalra@amd.com>]

Hello Alan, Paolo,

I am following up on Brijesh’s patches for SEV guest debugging support for Qemu using gdb and/or qemu monitor.
I believe that last time, Qemu SEV debug patches were not applied and have attached the link to the email thread and Paolo’s feedback below for reference [1].
I wanted to re-start a discussion on the same here with the Qemu community and seek the feedback on the approaches which we are considering :
Looking at Qemu code, I see the following interface is defined, for virtual memory access for debug : cpu_memory_rw_debug(). 
Both gdbstub (target_memory_rw_debug() ) and QMP/HMP (monitor/misc.c : memory_dump() ) use this standard and well-defined interface to access guest memory for debugging purposes. 

This internally invokes the address_space_rw() accessor functions which we had  "fixed" internally (as part of the earlier patch) to invoke memory region specific debug ops. 
In our earlier approach we were adding debug ops/callbacks to memory regions and as per comments on our earlier patches, Paolo was not happy with this debug API for
MemoryRegions and hence the SEV support for Qemu was merged without the debug support.

Now, we want to reuse this cpu_memory_rw_debug() interface or alternatively introduce a new generic debug interface/object in the Qemu. This 
debug interface should be controlled through the global machine policy.

For e.g., 
# $QEMU -machine -debug=<a debug object>
or
# $QEMU -machine -debug=sev-guest-debug

The QMP and GDB access will be updated to use the generic debug  interface. The generic debug interface or the cpu_memory_rw_debug() interace will introduce hooks to call a 
vendor specific debug object to delegate accessing the data. The vendor specific debug object may do a further checks before and after accessing the memory.

Now, looking specifically at cpu_memory_rw_debug() interface, this interface is invoked for all guest memory accesses for debugging purposes and it also does 
guest VA to GPA translation via cpu_get_phys_page_attrs_debug(), so we can again add a vendor specific callback here to do guest VA to GPA translations specific
to SEV as SEV guest debugging will also require accessing guest page table entries and decrypting them via the SEV DBG_DECRYPT APIs and additionally clearing
the C-bit on page table entries (PxEs) before using them further for page table walks.

There is still an issue with the generic cpu_memory_rw_debug() interface, though it is used for all guest memory accesses for debugging and we can also handle
guest page table walks via it (as mentioned above), there are still other gdb/monitor commands such as tlb_info_xx() and mem_info_xx() which also do guest page
table walks, but they don’t go through any generic guest memory access/debug interface, so these commands will need to be handled additionally for SEV.

The vendor specific debug object (added as a hook to generic debug object or the generic cpu_memory_rw_debug() interface) will do further checks before and after accessing the memory.

e.g., in the case of SEV,

1. Check the guest policy, if guest policy does not allow debug then return an error.

2. If its an MMIO region then access the data.

3. If its RAM region then call the PSP commands to decrypt the data.

4. If caller asked to read the PTE entry then probably clear the C-bits after reading the PTE entry.

5. many more checks

Looking fwd. to your feedback/comments on the above approach or other any other suggestions.

Thanks,
Ashish

[1] -> http://next.patchew.org/QEMU/20180308124901.83533-1-brijesh.singh@amd.com/20180308124901.83533-29-brijesh.singh@amd.com/