From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH V5 3/3] xen/vm_event: Deny register writes if refused by vm_event reply Date: Tue, 14 Jul 2015 16:55:48 +0100 Message-ID: <55A54D240200007800090DF6@mail.emea.novell.com> References: <1436807687-9826-1-git-send-email-rcojocaru@bitdefender.com> <1436807687-9826-4-git-send-email-rcojocaru@bitdefender.com> <55A51E1D0200007800090AF4@mail.emea.novell.com> <55A5126B.7070600@bitdefender.com> <55A53BBD0200007800090D05@mail.emea.novell.com> <55A5250B.8050305@bitdefender.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A5250B.8050305@bitdefender.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Razvan Cojocaru Cc: jun.nakajima@intel.com, kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, eddie.dong@intel.com, Aravind.Gopalakrishnan@amd.com, suravee.suthikulpanit@amd.com, tlengyel@novetta.com, keir@xen.org, boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org >>> On 14.07.15 at 17:04, wrote: > On 07/14/2015 05:41 PM, Jan Beulich wrote: >>>>> On 14.07.15 at 15:45, wrote: >>> On 07/14/2015 03:35 PM, Jan Beulich wrote: >>>>>>> On 13.07.15 at 19:14, wrote: >>>>> --- a/xen/arch/x86/vm_event.c >>>>> +++ b/xen/arch/x86/vm_event.c >>>>> @@ -22,11 +22,19 @@ >>>>> >>>>> #include >>>>> #include >>>>> +#include >>>>> >>>>> int vm_event_init_domain(struct domain *d) >>>>> { >>>>> struct vcpu *v; >>>>> >>>>> + if ( !d->arch.event_write_data ) >>>>> + d->arch.event_write_data = xzalloc_array(struct monitor_write_data, >>>>> + d->max_vcpus); >>>> >>>> Looking at this again I wonder why the data isn't being made part of >>>> struct arch_vcpu's vm_event sub-structure. That would also address >>>> the complaint I have here about this not being a guaranteed maximum >>>> page size runtime allocation. >>> >>> I think this is just how the initial suggestion was worded, I'll change it. >> >> Right - after having sent the reply I started wondering whether >> maybe I had asked for this. But if I did, then surely not with >> xzalloc_array(), but vzalloc(). >> >> If you moved this into struct arch_vcpu (again), then its size would >> likely call for the whole vm_event structure to become indirectly >> accessed and allocated. > > In that case would it suffice to just switch to vzalloc() in this case? For now, yes. > I'm not opposed to just placing all the data (this and the > memory-content hiding data) in struct vm_event and allocate that as a > whole, but that would change patch 1/3, 3/3 and also touch other code. Would be a nice thing to clean up post-4.6. Jan