[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 5/9] xen: Support for VMCALL mem_events



>>> On 02.07.14 at 18:23, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> On 07/02/2014 07:11 PM, Jan Beulich wrote:
>>>>> On 02.07.14 at 17:54, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>> --- a/xen/include/public/hvm/params.h
>>>>> +++ b/xen/include/public/hvm/params.h
>>>>> @@ -148,6 +148,8 @@
>>>>>  #define HVM_PARAM_IOREQ_SERVER_PFN 32
>>>>>  #define HVM_PARAM_NR_IOREQ_SERVER_PAGES 33
>>>>>  
>>>>> -#define HVM_NR_PARAMS          34
>>>>> +#define HVM_PARAM_MEMORY_EVENT_VMCALL 34
>>>>
>>>> So why does this (used only as an argument to
>>>> hvm_memory_event_traps()) need to be settable? I guess the patch
>>>> description is just too brief.
>>>
>>> Settable?
>> 
>> You must have a reason to make this a HVM param. That reason is
>> what I'm asking for.
> 
> I see. I want to be able to enable / disable this type of events. I.e.:
> 
> if (flags & ENABLE_VMCALL)
>     xc_set_hvm_param(xci, domain, HVM_PARAM_MEMORY_EVENT_VMCALL,
>                      HVMPME_mode_sync);
> 
> from the application, via libxc.

But hvm_memory_event_vmcall() simply uses the value, whether or
not it got set. And if the receiver of the event has to anyway deal
with instances it didn't enable, then it needs to do filtering anyway,
and hence there's little point in making configurable the exact value
being passed back up.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.