From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH RFC v2 1/4] x86/mm: Shadow and p2m changes for PV mem_access Date: Thu, 28 Aug 2014 21:00:30 +0200 Message-ID: <20140828190030.GA2147@deinos.phlegethon.org> References: <1404787805-4540-1-git-send-email-aravindp@cisco.com> <1404787805-4540-2-git-send-email-aravindp@cisco.com> <53D13457020000780002599B@mail.emea.novell.com> <97A500D504438F4ABC02EBA81613CC633188B795@xmb-aln-x02.cisco.com> <53D221270200007800025CEA@mail.emea.novell.com> <97A500D504438F4ABC02EBA81613CC633188BE3A@xmb-aln-x02.cisco.com> <20140828091442.GB60905@deinos.phlegethon.org> <97A500D504438F4ABC02EBA81613CC63318E4DD6@xmb-aln-x02.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XN4w9-0007iv-4T for xen-devel@lists.xenproject.org; Thu, 28 Aug 2014 19:00:45 +0000 Content-Disposition: inline In-Reply-To: <97A500D504438F4ABC02EBA81613CC63318E4DD6@xmb-aln-x02.cisco.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Aravindh Puthiyaparambil (aravindp)" Cc: "xen-devel@lists.xenproject.org" , Keir Fraser , Ian Jackson , Jan Beulich , Ian Campbell List-Id: xen-devel@lists.xenproject.org At 18:31 +0000 on 28 Aug (1409247071), Aravindh Puthiyaparambil (aravindp) wrote: > >> >That's not necessarily enough, but at least presumably the right > >> >route: You also need to avoid fiddling with struct page_info fields > >> >that may be used (now or in the future) for other purposes, i.e. > >> >you need to gate the setting of the flags by more than just > >> >is_pv_domain(). > >> > >> Coupled with your response to the other thread, I am thinking I should > >move away from using the shadow_flags for access permissions. Tim's other > >suggestion was to try and re-use the p2m-pt implementation. > >> > > > >I think you should be OK to use shadow_flags here -- after all the > >shadow code relies on being able to use them for any guest data page > >once shadow mode is enabled. > > Yes, I agree. In fact using the p2m-pt implementation is not going to help getting around the hypercall continuation issue. > > >To avoid touching them before shadow mode is actually enabled you > >could reshuffle the encodings so that 0 is 'default' (shadow code > >absolutely relies on this field being 0 when shadow more is enabled so > >any other user will have to maintain that). > > Do you mean the p2m_access_t enum when you say encoding? Not necessarily - but you _could_ reorder the enum (and add a comment so make sure that other people don't reorder it again) if that does what you want. Alternatively, you could use one more bit of the shadow flags as a 'valid' bit for the access bits, where readers would replace invalid mappings with whatever the correct default value is. One other question occurs to me: what about the case of enabling, disabling and re-enabling the mem-access feature? Is it OK that access permissions will be retained from the first use into the second or do they need to be reset somehow? Cheers, Tim.