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

Re: [Xen-devel] [PATCH 4/5] xen/vm_event: Deny MSR writes if refused by vm_event reply



On 05/11/2015 10:03 AM, Jan Beulich wrote:
>>>> On 08.05.15 at 19:05, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 05/08/2015 07:23 PM, Jan Beulich wrote:
>>>>>> On 06.05.15 at 19:12, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> --- a/xen/include/asm-x86/domain.h
>>>> +++ b/xen/include/asm-x86/domain.h
>>>> @@ -518,6 +518,11 @@ struct arch_vcpu
>>>>          struct vm_event_emul_read_data emul_read_data;
>>>>      } vm_event;
>>>>  
>>>> +    struct {
>>>> +        bool_t do_write;
>>>> +        uint64_t msr;
>>>> +        uint64_t value;
>>>> +    } msr_write;
>>>>  };
>>>
>>> Again a growth of struct vcpu by 24 bytes for everyone even though
>>> quite likely only very few VMs would actually need this. To be honest
>>> I'd even be hesitant to accept a pointer addition here. Perhaps this
>>> should be a suitably sized, dynamically allocated array hanging off of
>>> struct domain?
>>
>> Sorry, I don't follow the dynamically allocated _array_ part. Could you
>> please give a small example of what you mean?
> 
> Have a pointer in struct arch_domain which gets populated only
> when needed, and if so by an array allocation with the array
> dimension being the maximum number of vCPU-s the domain may
> have. That way the memory overhead for non-monitored domains
> is a pointer per domain (as opposed to quite a bit more unused
> space per vCPU).

All clear now.


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