[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/5] xen/vm_access: Support for memory-content hiding
>>> On 08.06.15 at 12:02, <rcojocaru@xxxxxxxxxxxxxxx> wrote: > On 05/08/2015 07:07 PM, Jan Beulich wrote: >>> > --- a/xen/include/asm-x86/domain.h >>> > +++ b/xen/include/asm-x86/domain.h >>> > @@ -512,6 +513,7 @@ struct arch_vcpu >>> > uint32_t emulate_flags; >>> > unsigned long gpa; >>> > unsigned long eip; >>> > + struct vm_event_emul_read_data emul_read_data; >> Considering the size of this structure I don't think this should be >> there for all vCPU-s of all guests. IOW - please allocate this >> dynamically only on domains where it's needed. > > Looking at the code, it's not immediately clear how to differentiate > between a domain where this is needed and one where it is not. At domain > init time we don't know, because it might become needed as soon as a > vm_event client becomes attached to the domain. Then again, even once a > vm_event client attaches to the domain, it might still not be necessary > to allocate that structure, as the client might never reply with > MEM_ACCESS_SET_EMUL_READ_DATA. > > The only place where we know for sure that it's needed is in > p2m_mem_access_check(), when receiving a vm_event response with > MEM_ACCESS_SET_EMUL_READ_DATA (lazy allocation). Would this be alright? I can't really judge about that; the farther you can safely defer it, the better. For the sake of addressing my complaint it would probably suffice to defer it until a vm_event client attaches to the guest. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |