xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: kevin.tian@intel.com, sstabellini@kernel.org,
	suravee.suthikulpanit@amd.com, andrew.cooper3@citrix.com,
	xen-devel@lists.xen.org, julien.grall@arm.com,
	tamas@tklengyel.com, jun.nakajima@intel.com,
	boris.ostrovsky@oracle.com
Subject: Re: [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT
Date: Fri, 11 Nov 2016 17:16:35 +0200	[thread overview]
Message-ID: <3e79c0b8-41ad-b8ed-edfb-39f1187c60b2@bitdefender.com> (raw)
In-Reply-To: <5825B516020000780011DF25@prv-mh.provo.novell.com>

On 11/11/2016 01:09 PM, Jan Beulich wrote:
>>>> On 11.11.16 at 11:32, <rcojocaru@bitdefender.com> wrote:
>> On 11/11/2016 12:26 PM, Jan Beulich wrote:
>>>>>> On 11.11.16 at 11:15, <rcojocaru@bitdefender.com> wrote:
>>>>> On 11/11/2016 12:02 PM, Jan Beulich wrote:
>>>>>>>>>>>>> On 11.11.16 at 09:06, <rcojocaru@bitdefender.com> wrote:
>>>>>>>>> --- a/xen/include/asm-x86/domain.h
>>>>>>>>> +++ b/xen/include/asm-x86/domain.h
>>>>>>>>> @@ -576,6 +576,10 @@ struct arch_vcpu
>>>>>>>>>      XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
>>>>>>>>>  
>>>>>>>>>      struct arch_vm_event *vm_event;
>>>>>>>>> +
>>>>>>>>> +    struct {
>>>>>>>>> +        unsigned int next_interrupt_enabled : 1;
>>>>>>>
>>>>>>> bool? Stray spaces. And then (sorry for thinking of this only now) - is
>>>>>>> this really usefully an arch-specific flag? I guess there's nothing
>>>>>>> precluding this from also being implemented on ARM eventually?
>>>>>
>>>>> Stray spaces? Do you mean the newline between "struct arch_vm_event
>>>>> *vm_event;" and "struct {"?
>>> No. I mean the ones around the colon.
>>
>> I'm sorry, I don't follow. The examples I've pasted in the previous
>> reply make similar use of the colon:
>>
>> 399     /* Arch-specific monitor options */
>> 400     struct {
>> 401         unsigned int write_ctrlreg_enabled       : 4;
>> 402         unsigned int write_ctrlreg_sync          : 4;
>> 403         unsigned int write_ctrlreg_onchangeonly  : 4;
>> 404         unsigned int singlestep_enabled          : 1;
>> 405         unsigned int software_breakpoint_enabled : 1;
>> 406         unsigned int debug_exception_enabled     : 1;
>> 407         unsigned int debug_exception_sync        : 1;
>> 408         unsigned int cpuid_enabled               : 1;
>> 409         struct monitor_msr_bitmap *msr_bitmap;
>> 410     } monitor;
>>
>> and
>>
>> 130     /* Monitor options */
>> 131     struct {
>> 132         uint8_t privileged_call_enabled : 1;
>> 133     } monitor;
>>
>> I take that you would prefer this?
>>
>> unsigned int next_interrupt_enabled:1;
>>
>> I have nothing against the change, I'm just confused about what the
>> proper and consistent way of writing that is.
> 
> grep-ing the include/ subtree I see that there are (apart from the
> quoted ones) examples of all kinds, so I guess it can as well stay as
> is, even if I personally consider the blanks stray here.

Alright, thanks! So since Tamas has given his ack, I guess all that's
required now is to const-ify struct vmcb_struct *vmcb in
svm_get_pending_event() (and also I now see in the examples above that a
uint8_t is probably better suited than an unsigned int for
next_interrupt_enabled, so that it will take less space in struct arch_vcpu.

I'll submit V4 shortly with these two changes.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2016-11-11 15:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-11  8:06 [PATCH V3] x86/vm_event: Added support for VM_EVENT_REASON_INTERRUPT Razvan Cojocaru
2016-11-11 10:02 ` Jan Beulich
2016-11-11 10:15   ` Razvan Cojocaru
2016-11-11 10:26     ` Jan Beulich
2016-11-11 10:32       ` Razvan Cojocaru
2016-11-11 11:09         ` Jan Beulich
2016-11-11 15:16           ` Razvan Cojocaru [this message]
2016-11-11 15:33             ` Jan Beulich
2016-11-11 15:39               ` Razvan Cojocaru
2016-11-11 15:09 ` Tamas K Lengyel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3e79c0b8-41ad-b8ed-edfb-39f1187c60b2@bitdefender.com \
    --to=rcojocaru@bitdefender.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=julien.grall@arm.com \
    --cc=jun.nakajima@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tamas@tklengyel.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).