| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: Linux Stubdom Problem
|
To: |
Jiageng Yu <yujiageng734@xxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] Re: Linux Stubdom Problem |
|
From: |
Tim Deegan <tim@xxxxxxx> |
|
Date: |
Fri, 2 Sep 2011 12:03:16 +0100 |
|
Cc: |
"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Keir Fraser <keir.xen@xxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxx>, Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> |
|
Delivery-date: |
Fri, 02 Sep 2011 04:04:33 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<CAJ0pt14GRw9mvR6YpgD+svoRAL=pO9ki5jdp0XfHCcdebQ9ahA@xxxxxxxxxxxxxx> |
|
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: |
<alpine.DEB.2.00.1108291636010.12963@kaball-desktop> <CA838CEF.1FFF2%keir.xen@xxxxxxxxx> <CAJ0pt15Mybn7VH4YH6eV+yONtJpVK=fFcpmZ3sGUcD55DW26Zg@xxxxxxxxxxxxxx> <20110901172728.GH3859@xxxxxxxxxxxxxxxxxxxxx> <CAJ0pt14GRw9mvR6YpgD+svoRAL=pO9ki5jdp0XfHCcdebQ9ahA@xxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mutt/1.4.2.1i |
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
|
|
|
| |
|
Home