| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: Linux Stubdom Problem
|
To: |
Tim Deegan <tim@xxxxxxx> |
|
Subject: |
Re: [Xen-devel] Re: Linux Stubdom Problem |
|
From: |
Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> |
|
Date: |
Fri, 2 Sep 2011 14:09:10 +0100 |
|
Cc: |
Anthony, "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>, Jiageng Yu <yujiageng734@xxxxxxxxx>, PERARD <anthony.perard@xxxxxxxxx>, Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> |
|
Delivery-date: |
Fri, 02 Sep 2011 06:04:06 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<20110902110316.GA30893@xxxxxxxxxxxxxxxxxxxxx> |
|
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> <20110902110316.GA30893@xxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Alpine 2.00 (DEB 1167 2008-08-23) |
On Fri, 2 Sep 2011, Tim Deegan wrote:
> 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.
I think think that leaking the implementation details of the device
model into hvmloader should be avoided, but obviously if there are no
alternatives, it can be done.
> > 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.
OK. I think we'll try the other approach first to see if it is easier:
modify Linux xen-fbfront driver to take a list of pages from the guest
for the vram.
> > 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.
We could fully re-implement xen-fbfront in userspace inside qemu, at
that point the problem would go away completely.
Rather than duplicating all that code, we'll try to reuse Linux
xen-fbfront implementation, making sure that xen-fbfront is loaded after
qemu is started and initialized.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home