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

Re: [Xen-devel] Re: Linux Stubdom Problem

Hi, 

At 10:32 +0800 on 02 Sep (1314959538), Jiageng Yu wrote:
> 2011/9/2 Tim Deegan <tim@xxxxxxx>:
> > 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.

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