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/
Home Products Support Community News


Re: [Xen-devel] I cannot get any message from domU by console / pv_ops d

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] I cannot get any message from domU by console / pv_ops domU kernel crashes with xen_create_contiguous_region failed
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Tue, 22 Dec 2009 11:19:19 -0500
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, ?????? <peb1611@xxxxxxxxx>
Delivery-date: Tue, 22 Dec 2009 08:27:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1261498176.5965.6477.camel@xxxxxxxxxxxxxxxxxxxxxx>
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>
References: <ebf0d9030912210630p4b6b987fu423fa54420b55271@xxxxxxxxxxxxxx> <20091221183000.GO16033@xxxxxxxxxxx> <ebf0d9030912212002h6996f725kf4626bd02e03161b@xxxxxxxxxxxxxx> <20091222084214.GR16033@xxxxxxxxxxx> <1261473615.5965.3829.camel@xxxxxxxxxxxxxxxxxxxxxx> <20091222143540.GB2785@xxxxxxxxxxxxxxxxxxx> <1261493401.5965.5944.camel@xxxxxxxxxxxxxxxxxxxxxx> <20091222154747.GC5181@xxxxxxxxxxxxxxxxxxx> <1261498176.5965.6477.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.19 (2009-01-05)
On Tue, Dec 22, 2009 at 04:09:36PM +0000, Ian Campbell wrote:
> On Tue, 2009-12-22 at 15:47 +0000, Konrad Rzeszutek Wilk wrote:
> > > I thought it used to be that you could only (successfully) make order>0
> > > increase_reservation or mem_exchange hypercalls if you had I/O
> > > privileges? Has this changed?
> > 
> > I am looking at the 3.4 code I am not seeing any I/O privileges check.
> > 
> > I did not even know that those existed actually - could you give me an idea
> > when was the last time you saw it?
> In xen-unstable multipage_allocation_permitted is called from
> memory_exchange() and increase_reservation() and is defined as 
> #define multipage_allocation_permitted(d, order)        \
>     (((order) <= 9) || /* allow 2MB superpages */       \
>      !rangeset_is_empty((d)->iomem_caps) ||             \
>      !rangeset_is_empty((d)->arch.ioport_caps))
> The ((order) <= 9) || is new and isn't present in the 3.4 tree,
> previously you would have had to add a passthrough device to cause one
> of the other rangesets to become non-empty. 

AAh, and since the exchange of memory is done in small chunks we pass
underneath the radar even if did not have the passthrough device set.

Ian, thanks for finding the culprit. Let me roll out a patch that
will do what was done in the past (ie, turn SWIOTLB for DomU only
when iommu=soft was passed in) as a fix.

Later (next year) I can propose the more dynamic SWIOTLB mechanism
that should make this more automatic.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>