Re: Re: Linux Stubdom Problem

[Tim Deegan <tim@xen.org>]

Hi, 

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