WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH 6/8] xen/debug: WARN_ON when 1-1 but no _PAGE_IOM

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH 6/8] xen/debug: WARN_ON when 1-1 but no _PAGE_IOMAP flag set.
From: Keir Fraser <keir@xxxxxxx>
Date: Thu, 06 Jan 2011 20:17:38 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>, "hpa@xxxxxxxxx" <hpa@xxxxxxxxx>
Delivery-date: Thu, 06 Jan 2011 12:19:07 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:user-agent:date :subject:from:to:cc:message-id:thread-topic:thread-index:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=yGT5n8DNSM/FCooR8w0vqQn4dd89po/sB0eU3CZ85Cw=; b=dwgmc6IUU4CHydmmuX6tzZheLWxTY8mhTe5k/VNptCn/Ls2oH7MlonQG+nFjfxFz3/ mchAT+d4GVOr3rJyeyReBLuLLUw4c61Kg1zHoLUdPU4L/48XtSnbKUbqMfrtiRocBJKs xXEjJ2XNLvjSkI5DI32LpIN7efjrv9ybLrGW0=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=PAbfykzuDhoNddS9Q4tVmgfw2rlNzmIX8GsQca6SMRMaSndknA2JqmfUAga5PdHd6+ BlguA/mQ6JaeXpz0ZXBzyyAH6NHOMigZAhMigzPsai1sNp3dp8zHYywbS8aCLMvCp/uk wWN6lw2gPjVKLUeBUSbGw16eNfGO91l0ckrvE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1101061935070.2390@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acut3sM7bPsuIasjvUmOAukRZamReg==
Thread-topic: [PATCH 6/8] xen/debug: WARN_ON when 1-1 but no _PAGE_IOMAP flag set.
User-agent: Microsoft-Entourage/12.28.0.101117
On 06/01/2011 19:50, "Stefano Stabellini" <stefano.stabellini@xxxxxxxxxxxxx>
wrote:

>> Perhaps this ties in with the m2p overlay which Stefano+Jeremy have been
>> working on to deal with granted foreign pages? I/O pages are a bit like
>> foreign memory (if you squint enough)...
>  
> In theory the m2p overlay could be used for this purpose but in practice
> the current m2p overlay API needs a struct page, also it might end up
> stressing the hashtable too much.
> 
> Besides I think Konrad's solution might be simpler: if the m2p returns
> one of the two special values we just return mfn from pte_mfn_to_pfn.
> 
> Keir, could you confirm that the m2p entries of DOM_IO pages are always
> 0xffffff or 0x55555?

Always 0x55...55 (for m2p entries that exist), else page fault on access to
the non-existent m2p entry (m2p entries only guaranteed to exist for ram).
Perhaps the 0xff...ff values come from Linux's own fixup code handling a
faulting read access of the m2p array? If so you could return 0x55...55
instead and avoid checking for 0xff...ff. I really don't know how you could
get 0xff...ff for non-RAM pages from Xen itself.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel