| |
|
 |
|
 |
|
|
|
| |
|
|
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: |
Mon, 29 Aug 2011 17:03:19 +0100 |
|
Cc: |
"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Samuel, Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, Konrad, Jiageng Yu <yujiageng734@xxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxx>, Thibault <samuel.thibault@xxxxxxxxxxxx> |
|
Delivery-date: |
Mon, 29 Aug 2011 09:11:22 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<20110829131845.GA7850@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: |
<CAJ0pt155eqcyUwd-m--m3n+t-hLYixe+xA8J5MWgEWj58+o_Gw@xxxxxxxxxxxxxx> <CAJ0pt14OXshWn5NQ3JSfqRNdHkWMyhKWC0OwMixu9Xmk0b1oqw@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1108190027450.12963@kaball-desktop> <CAJ0pt16CLqt+bHUwvO_V=c39CqN4Y4BCgbcSW26wik4hFTHq_g@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1108221834340.12963@kaball-desktop> <20110823100719.GD96414@xxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1108231350380.12963@kaball-desktop> <alpine.DEB.2.00.1108261709210.12963@kaball-desktop> <20110827130657.GA44193@xxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1108291324590.12963@kaball-desktop> <20110829131845.GA7850@xxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Alpine 2.00 (DEB 1167 2008-08-23) |
On Mon, 29 Aug 2011, Tim Deegan wrote:
> At 13:27 +0100 on 29 Aug (1314624464), Stefano Stabellini wrote:
> > > So it is; I had misremembered the interface. GNTTABOP_map_grant_ref is
> > > the hypercall to map granted pages into the p2m.
> >
> > Are you sure? I think that GNTTABOP_map_grant_ref maps foreign granted
> > pages into our own domain, in fact it takes a domid and a grant table
> > reference as input parameters to specify the source page, host_addr is
> > the destination in our own domain.
>
> Oh, so it will. You'd need to arrange for that to be called from inside
> the guest; or you could implement an add_to_physmap space for it; that
> could be called from another domain.
"From inside the guest" means hvmloader?
The good thing about doing it in hvmloader is that we could use the
traditional PV frontend/backend mechanism to share pages. On the other
hand hvmloader doesn't know if we are using stubdoms at the moment and
it would need to issue the grant table hypercall only in that case.
Unless we decide to always grant the videoram to guests but it would
change once again the domain to which the videoram is accounted for
(dom0/stubdom rather than the guest, that is a bad thing).
Also I don't like the idea of making hvmloader stubdom aware.
Thus I would choose the other option: implement an add_to_physmap space
for mapping grant references to another domain. Basically it would be
like what you suggested before (XENMAPSPACE_grant_table) but actually
mapping the granted pages rather than the pages constituting the grant
table :-)
However that means that with stubdoms the videoram is accounted to the
stubdom while without stubdoms the videoram is accounted to the guest.
I think we'll have to live with this inconsistency (the only other
solution would be to reimplement xen-fbfront in qemu).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home