Re: [Xen-devel] [PATCH] x86/debug: Plumb pending_dbg through the monitor and devicemodel interfaces

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Tue, Dec 3, 2019 at 1:18 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 03/12/2019 18:09, Tamas K Lengyel wrote:
> > On Tue, Dec 3, 2019 at 1:05 PM Tamas K Lengyel <tamas@xxxxxxxxxxxxx> wrote:
> >>> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> >>> index 959083d8c4..76676ff4c0 100644
> >>> --- a/xen/include/public/vm_event.h
> >>> +++ b/xen/include/public/vm_event.h
> >>> @@ -281,6 +281,7 @@ struct vm_event_debug {
> >>>      uint32_t insn_length;
> >>>      uint8_t type;        /* HVMOP_TRAP_* */
> >>>      uint8_t _pad[3];
> >>> +    uint64_t pending_dbg;
> >> This is just a nitpick but I would prefer if we had the _pad field as
> >> the last element in the struct and keep all 64-bit members up in the
> >> front.
> > Also, since pending_dbg uses unsigned int in Xen, do we need uint64_t
> > for it here? Seems to me a uint32_t would suffice.
>
> Its %dr6 (but not quite, due to complexity with exception priorities,
> interrupt shadows, and backwards compatibility of the RTM bit with
> inverted polarity).  All other registers have 64 bit fields in the
> interface.
>
> The only interesting bits in it fall within the first 32 which is why it
> is handled in a shorter way within Xen.  Like %cr0, I don't expect
> anything interesting to appear in the upper 32 bits.
>

Perhaps it would be better to call it dr6 in the interface then to
make it more clear that this is a register value?

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel