* Peter Maydell (peter.maydell@xxxxxxxxxx) wrote: > On Tue, 1 Dec 2020 at 11:51, Dr. David Alan Gilbert <dgilbert@xxxxxxxxxx> wrote: > > > > * Peter Maydell (peter.maydell@xxxxxxxxxx) wrote: > > > On Mon, 16 Nov 2020 at 19:28, Ashish Kalra <Ashish.Kalra@xxxxxxx> wrote: > > > > > > > > From: Brijesh Singh <brijesh.singh@xxxxxxx> > > > > > > > > From: Brijesh Singh <brijesh.singh@xxxxxxx> > > > > > > > > Extend the MemTxAttrs to include a 'debug' flag. The flag can be used as > > > > general indicator that operation was triggered by the debugger. > > > > > > > > A subsequent patch will set the debug=1 when issuing a memory access > > > > from the gdbstub or HMP commands. This is a prerequisite to support > > > > debugging an encrypted guest. When a request with debug=1 is seen, the > > > > encryption APIs will be used to access the guest memory. > > > > > > So, what counts as "debug" here, and why are debug requests > > > special? If "debug=1" means "can actually get at the guest memory", > > > why wouldn't every device model want to use it? > > > > SEV has a flag that the guest-owner can set on a VM to enable debug; > > it's rare for it to be enabled; so it's not suitable for use by normal > > devices. It's only there for debug if the guest owner allows you to. > > So if I do a memory transaction with debug=1 then I should expect > that it might come back with a failure status (meaning "this VM > doesn't permit debug") and I should handle that error ? I think that's probably true. Dave > thanks > -- PMM > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
