SEV guest debugging support for Qemu

[Ashish Kalra]

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/