From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Re: Linux Stubdom Problem Date: Fri, 2 Sep 2011 12:03:16 +0100 Message-ID: <20110902110316.GA30893@ocelot.phlegethon.org> References: <20110901172728.GH3859@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jiageng Yu Cc: "xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk , Ian Campbell , Keir Fraser , Anthony PERARD , Samuel Thibault List-Id: xen-devel@lists.xenproject.org Hi, At 10:32 +0800 on 02 Sep (1314959538), Jiageng Yu wrote: > 2011/9/2 Tim Deegan : > > I would really rather not have this interface; I don't see why we can't > > use grant tables for this. > > In linux based stubdom case, we want to keep hvm guest and its > hvmloader unaware of running on stubdom. Why? HVMloader is already tightly coupled to the hypervisor and the toostack - special cases for stubdoms should be fine. > Therefore, we do need a way > to map vram pages of stubdom into guest hvm transparently. I've suggested two so far: have grant mappings done from inside the guest, or add a XENMAPSPACE that takes grant IDs. I think the XENMAPSPACE is better; I suspect that save/restore will be easier to get right that way. > Additionally, if I modified grant table to map pages without any > participation of hvm guest(or hvmloader), it will obey the design > goals of grant table. So I think grant table may not be suitable for > our case. I don't understand you. > Another idea is to allocate vram in hvm guest and stubdom maps vram > pages into its memory space. Sure. The minios-based stubdoms seem to manage that just fine. If this is really difficult for a linux-based stub domain, then maybe that's a reason not to use them. Cheers, Tim.