On 03/12/2019 18:09, Tamas K Lengyel wrote:
> On Tue, Dec 3, 2019 at 1:05 PM Tamas K Lengyel <ta...@tklengyel.com> 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.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
