[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEV guest debugging support for Qemu
From: |
Dr. David Alan Gilbert |
Subject: |
Re: SEV guest debugging support for Qemu |
Date: |
Thu, 24 Sep 2020 14:53:42 +0100 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
* Ashish Kalra (ashish.kalra@amd.com) wrote:
> 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.
Let me leave the question of how the memory_rw_debug interface should
work to Paolo.
> 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.
I'm not sure that needs a commandline switch for it; since you can
already get it from the guest policy in the sev object and I can't think
of any other cases that would need something similar.
> 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.
If some of those should be using the debug interface and aren't then
please fix them anyway.
> 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.
Does that work if the guest is currently running?
Dave
> 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/
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Re: SEV guest debugging support for Qemu, Paolo Bonzini, 2020/09/25