From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] hvmloader / qemu-xen: Getting rid of resource conflict for OpRegion. Date: Thu, 20 Dec 2012 14:19:22 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "G.R." Cc: Stefano Stabellini , Ian Campbell , "Jean.guyader@gmail.com" , xen-devel List-Id: xen-devel@lists.xenproject.org On 20/12/2012 13:31, "G.R." wrote: > If concern is about security, the same argument should apply to the > first page (the portion before the page offset). > The problem is that I have no idea what is around the mapped page. Not > sure who has the knowledge. Well we can't do better than mapping some whole number of pages, really. Unless we trap to qemu on every access. I don't think we'd go there unless there really were a known security issue. But mapping only the exact number of pages we definitely need is a good principle. > What's the standard flow to handle such map with offset? > I expect this to be a common case, since the ioremap function in linux > kernel accept this. map_size = ((host_opregion & 0xfff) + 8096 + 0xfff) >> 12 Possibly with suitable macros used instead of magic numbers (e.g., XC_PAGE_* and a macro for the opregion size). -- Keir