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

Re: [Xen-devel] [PATCH V6] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event



On 05/27/2015 04:12 PM, Jan Beulich wrote:
>>>> On 27.05.15 at 10:17, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> As suggested by Andrew Cooper, this patch attempts to remove
>> some redundancy and allow for an easier time when adding vm_events
>> for new control registers in the future, by having a single
>> VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0,
>> CR3, CR4 and (newly introduced) XCR0. The actual control register
>> will be deduced by the new .index field in vm_event_write_ctrlreg
>> (renamed from vm_event_mov_to_cr). The patch has also modified
>> the xen-access.c test - it is now able to log CR3 events.
>>
>> Signed-off-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
>> Reviewed-by: Tim Deegan <tim@xxxxxxx>
> 
> Can this really still be considered applicable, with there having been
> changes that surely weren't just cosmetic?

I thought so, but obviously it wasn't a good call - I'll remove
Reviewed-by tags from future patches that go beyond the most trivial
kind of changes (and of course, for this one in V7).

>> @@ -88,55 +89,28 @@ static int hvm_event_traps(uint8_t sync, 
>> vm_event_request_t *req)
>>      return 1;
>>  }
>>  
>> -static inline
>> -void hvm_event_cr(uint32_t reason, unsigned long value,
>> -                         unsigned long old, bool_t onchangeonly, bool_t 
>> sync)
>> +void hvm_event_cr(unsigned int index, unsigned long value, unsigned long 
>> old)
> 
> If this builds then there is a (pre-existing) problem: The header
> declaring a function should be included by the source file defining
> it. And if that was the case, the function name should require
> parenthesization to suppress macro expansion. By not dealing with
> this now the patch would introduce a latent issue (surfacing as soon
> as the header, perhaps indirectly, gets included).

It did, I always check that at least "make dist" works before submitting
my patches. Indeed it compiled because event.c did not include event.h,
and it ceased to compile as soon as it was included.

Will fix it in V7.

>> --- a/xen/include/asm-x86/hvm/event.h
>> +++ b/xen/include/asm-x86/hvm/event.h
>> @@ -19,14 +19,14 @@
>>  #define __ASM_X86_HVM_EVENT_H__
>>  
>>  /* Called for current VCPU on crX/MSR changes by guest */
>> -void hvm_event_cr0(unsigned long value, unsigned long old);
>> -void hvm_event_cr3(unsigned long value, unsigned long old);
>> -void hvm_event_cr4(unsigned long value, unsigned long old);
>> +void hvm_event_cr(unsigned int index, unsigned long value, unsigned long 
>> old);
>>  void hvm_event_msr(unsigned int msr, uint64_t value);
>>  /* Called for current VCPU: returns -1 if no listener */
>>  int hvm_event_int3(unsigned long gla);
>>  int hvm_event_single_step(unsigned long gla);
>>  
>> +#define hvm_event_cr(what, new, old) hvm_event_cr(VM_EVENT_X86_##what, new, 
>> old)
> 
> I would have wished for the macro to be immediately adjacent to the
> function declaration, so that the whole picture of what works how is
> visible at once.

Ack.


Thanks,
Razvan

_______________________________________________
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®.