Il lun 28 set 2020, 15:26 Ashish Kalra ha scritto:
> Hello Paolo,
>
> On Sat, Sep 26, 2020 at 02:02:20AM +0200, Paolo Bonzini wrote:
> > On 26/09/20 01:48, Ashish Kalra wrote:
> > > Thanks for your input, i have one additional query with reference to
> this support :
> > >
> > > For all explicitl
Hello Paolo,
On Sat, Sep 26, 2020 at 02:02:20AM +0200, Paolo Bonzini wrote:
> On 26/09/20 01:48, Ashish Kalra wrote:
> > Thanks for your input, i have one additional query with reference to this
> > support :
> >
> > For all explicitly unecrypted guest memory regions such as S/W IOTLB bounce
>
On 26/09/20 01:48, Ashish Kalra wrote:
> Thanks for your input, i have one additional query with reference to this
> support :
>
> For all explicitly unecrypted guest memory regions such as S/W IOTLB bounce
> buffers,
> dma_decrypted() allocated regions and for guest regions marked as
> "__bss_
Hello Paolo,
On Fri, Sep 25, 2020 at 10:56:10PM +0200, Paolo Bonzini wrote:
> 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
Hello Paolo,
Thanks for your response.
On Fri, Sep 25, 2020 at 10:51:05AM +0200, Paolo Bonzini wrote:
> On 22/09/20 22:11, Ashish Kalra wrote:
> > This internally invokes the address_space_rw() accessor functions
> > which we had "fixed" internally (as part of the earlier patch) to
> > invoke me
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
On 22/09/20 22:11, Ashish Kalra wrote:
> 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 a
>
> > > On Thu, Sep 24, 2020 at 02:53:42PM +0100, Dr. David Alan Gilbert wrote:
> > >> * Ashish Kalra (ashish.ka...@amd.com) wrote:
> > >>> Hello Alan, Paolo,
> > >>>
> > >>> I am following up on Brijesh’s patches for SEV gues
n Gilbert wrote:
> >> * Ashish Kalra (ashish.ka...@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 belie
,
>>>
>>> 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 f
Hello Dave,
Thanks for your response, please see my replies inline :
On Thu, Sep 24, 2020 at 02:53:42PM +0100, Dr. David Alan Gilbert wrote:
> * Ashish Kalra (ashish.ka...@amd.com) wrote:
> > Hello Alan, Paolo,
> >
> > I am following up on Brijesh’s patches for SEV guest
* Ashish Kalra (ashish.ka...@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
[AMD Public Use]
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
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
14 matches
Mail list logo
